Re: Plans for git (was: Please check the current beta git conversions)
resending, because I clearly have no clue. On Wed, Sep 2, 2020, at 2:50 PM, Ian Lepore wrote: > On Wed, 2020-09-02 at 14:45 -0400, Dan Langille wrote: > > On Wed, Sep 2, 2020, at 2:36 PM, Ian Lepore wrote: > > > > > Seriously, Warner? > > > > Yes, seriously. We are adults. Act accordingly. > > > > Don't be confused. I also thought the message he was replying to was out of > > line. > > > > > I applaud Steve's message as being the first one in this thread that > > > has any real value at all. Unlike everyone else, he has clearly seen > > > what the basic problem is (zero communications about this impending > > > cutover to the people who need to work with it every day), and he > > > summarized it in a completely practical way. > > > > We disagree. The message could have been worded without being negative. > > > > > This assumption that everyone knows how to use git is mind-boggling. I > > > think I installed it once, a few years ago. Then I uninstalled it > > > because of how abysmally hard it was to try to learn even a few > > > commands to do anything with it. > > > > No, it's assumed you will learn. I did. We all can. > > > > Please, we cooperate on this project. We don't attack, and yes, these were > > attacks. > > > > > I guess Steve & I are a couple dinosaurs and the whole rest of the > > > freebsd user and committer community is laughing at our ignorance and > > > thinking "we don't need their contributions anyway, so let's just mock > > > them and move on." > > > > I don't think so. I'm guessing I'm older and more set in my ways. > > > > There are much better ways to communicate that in recent messages. > > > > How typical: trim away ALL context of what's being discussed, then > claim that the material was offensive in some way after destroying the > contextual evidence that makes a lie of your claim. I apologize for the excessive trimming. I regret posting, but still persist in my call for improved methods. Umm, as for the rest... I don't know how to reply to that. -- Dan Langille d...@langille.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 2, 2020, at 2:50 PM, Ian Lepore wrote: > On Wed, 2020-09-02 at 14:45 -0400, Dan Langille wrote: > > On Wed, Sep 2, 2020, at 2:36 PM, Ian Lepore wrote: > > > > > Seriously, Warner? > > > > Yes, seriously. We are adults. Act accordingly. > > > > Don't be confused. I also thought the message he was replying to was out of > > line. > > > > > I applaud Steve's message as being the first one in this thread that > > > has any real value at all. Unlike everyone else, he has clearly seen > > > what the basic problem is (zero communications about this impending > > > cutover to the people who need to work with it every day), and he > > > summarized it in a completely practical way. > > > > We disagree. The message could have been worded without being negative. > > > > > This assumption that everyone knows how to use git is mind-boggling. I > > > think I installed it once, a few years ago. Then I uninstalled it > > > because of how abysmally hard it was to try to learn even a few > > > commands to do anything with it. > > > > No, it's assumed you will learn. I did. We all can. > > > > Please, we cooperate on this project. We don't attack, and yes, these were > > attacks. > > > > > I guess Steve & I are a couple dinosaurs and the whole rest of the > > > freebsd user and committer community is laughing at our ignorance and > > > thinking "we don't need their contributions anyway, so let's just mock > > > them and move on." > > > > I don't think so. I'm guessing I'm older and more set in my ways. > > > > There are much better ways to communicate that in recent messages. > > > > How typical: trim away ALL context of what's being discussed, then > claim that the material was offensive in some way after destroying the > contextual evidence that makes a lie of your claim. I apologize for the excessive trimming. I regret posting, but still persist in my call for improved methods. Umm, as for the rest... I don't know how to reply to that. -- Dan Langille d...@langille.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 2, 2020, at 2:36 PM, Ian Lepore wrote: > Seriously, Warner? Yes, seriously. We are adults. Act accordingly. Don't be confused. I also thought the message he was replying to was out of line. > I applaud Steve's message as being the first one in this thread that > has any real value at all. Unlike everyone else, he has clearly seen > what the basic problem is (zero communications about this impending > cutover to the people who need to work with it every day), and he > summarized it in a completely practical way. We disagree. The message could have been worded without being negative. > This assumption that everyone knows how to use git is mind-boggling. I > think I installed it once, a few years ago. Then I uninstalled it > because of how abysmally hard it was to try to learn even a few > commands to do anything with it. No, it's assumed you will learn. I did. We all can. Please, we cooperate on this project. We don't attack, and yes, these were attacks. > I guess Steve & I are a couple dinosaurs and the whole rest of the > freebsd user and committer community is laughing at our ignorance and > thinking "we don't need their contributions anyway, so let's just mock > them and move on." I don't think so. I'm guessing I'm older and more set in my ways. There are much better ways to communicate that in recent messages. -- Dan Langille d...@langille.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cannot access pass device from within jail
> On Dec 17, 2017, at 4:48 PM, Warner Losh <i...@bsdimp.com> wrote:
>
> Sorry to top post. The problem did turn out to be securelevel. We found
> this by doing
>
> dtrace -n 'fbt::securelevel_gt:return {print(args[1];)}'
>
> Though you could also replace securelevel_gt with passopen to see it was in
> passopen too...
On the host we ran:
[root@r710-01:~] # sudo dtrace -n 'fbt::securelevel_gt:return {print(args[1]);}'
dtrace: description 'fbt::securelevel_gt:return ' matched 1 probe
CPU IDFUNCTION:NAME
21 50269securelevel_gt:return int 0x1
In the jail: mtx -f /dev/pass7 status
Based on the dtrace output, I again checked securelevel in the jail:
[dan@bacula-sd-02] $ sysctl kern.securelevel
kern.securelevel: 2
WTF? I'd already checked that as seen at
https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007614.html
Oh wait. The above URL refers to bacula-sd-01, not bacula-sd-02. Ouch. User
error... me.
After going back into the host, I set:
$ sudo iocage set securelevel=1 bacula-sd-02
Property: securelevel has been updated to 1
After restarting the jail and getting back into it:
[root@bacula-sd-02 ~]# sysctl kern.securelevel
kern.securelevel: 1
[root@bacula-sd-02 ~]# mtx -f /dev/pass7 status
Storage Changer /dev/pass7:2 Drives, 47 Slots ( 0 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = 01L4
Success.
Sorry for the noise which would have been reduced if I'd gotten my sysctl on
the right host.
Thank you all.
>
> Warner
>
> On Sun, Dec 17, 2017 at 2:08 PM, Dan Langille <d...@langille.org> wrote:
>
>>> On Dec 17, 2017, at 4:04 PM, Warner Losh <i...@bsdimp.com> wrote:
>>>
>>> What's the permissions of /dev/xpt0 in the jail? If it's not there I know
>>> at least camcontrol won't work. I've not used mtx, so I can't say if it's
>>> affected too or not.
>>
>> I have tried both with and without xpt0. When I tried, it was:
>>
>> # ls -l /dev/xpt0
>> crw--- 1 root operator 0x4c Dec 16 21:52 /dev/xpt0
>>
>>>
>>> However, looking at the truss output:
>>>
>>> openat(AT_FDCWD,"/dev/pass7",O_RDWR|O_EXCL,00) ERR#1 'Operation not
>>> permitted'
>>> suggests something other than the canonical xpt0 issue else is going on.
>> If
>>> we look at passopen in cam, I can see two exit paths:
>>>
>>> error = securelevel_gt(td->td_ucred, 1); if (error != 0) {...
>>> return error; }
>>> securelevel_gt is just "return (cr->cr_prison->pr_securelevel > level ?
>>> EPERM : 0);" which might be possible. What's the securelevel of the jail?
>>> Maybe this is going on somehow?
>>
>>
>> On the host:
>>
>> $ sysctl kern.securelevel
>> kern.securelevel: -1
>>
>>
>> On the jail:
>>
>> $ sysctl kern.securelevel
>> kern.securelevel: -1
>>
>>>
>>> The second is basically
>>> if (((flags & FWRITE) == 0) || ((flags & FREAD) == 0)) {... return
>>> EPERM; }
>>> which isn't happening because of the O_RDWR in the truss output.
>>>
>>> The other possibility is that something above the pass driver is doing
>> the
>>> check. I've not looked at that code path yet, buy you can see if it's
>>> making it to passopen() with dtrace and checking its return value. I
>> don't
>>> see anything in how we register the device, though, that would suggest
>>> filtering it in jails.
>>>
>>> Warner
>>>
>>> On Sun, Dec 17, 2017 at 12:52 PM, Dan Langille <d...@langille.org> wrote:
>>>
>>>> Hello,
>>>>
>>>> What suggestions do you have for where I should look next? I'm happy to
>>>> start installing various builds of FreeBSD in order to track down which
>>>> commit caused this.
>>>>
>>>> I'm trying to access a tape library from within a jail running on a
>>>> FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0).
>>>>
>>>> pass(4) devices (i.e. the tape changer ch0) are not working. This
>> morning
>>>> I posted to -scsi@: https://lists.freebsd.org/
>> pipermail/freebsd-scsi/2017-
>>>> December/007608.html
>>>>
>>>> The device appears in the jail and has appropriate permissions. This
>>>> access was granted
>>>> via /etc/devfs.rules using the same approach I used for FreeBSD 10.3
>>>>
>>>> The permissions in the
Re: cannot access pass device from within jail
> On Dec 17, 2017, at 4:04 PM, Warner Losh <i...@bsdimp.com> wrote:
>
> What's the permissions of /dev/xpt0 in the jail? If it's not there I know
> at least camcontrol won't work. I've not used mtx, so I can't say if it's
> affected too or not.
I have tried both with and without xpt0. When I tried, it was:
# ls -l /dev/xpt0
crw--- 1 root operator 0x4c Dec 16 21:52 /dev/xpt0
>
> However, looking at the truss output:
>
> openat(AT_FDCWD,"/dev/pass7",O_RDWR|O_EXCL,00) ERR#1 'Operation not
> permitted'
> suggests something other than the canonical xpt0 issue else is going on. If
> we look at passopen in cam, I can see two exit paths:
>
>error = securelevel_gt(td->td_ucred, 1); if (error != 0) {...
> return error; }
> securelevel_gt is just "return (cr->cr_prison->pr_securelevel > level ?
> EPERM : 0);" which might be possible. What's the securelevel of the jail?
> Maybe this is going on somehow?
On the host:
$ sysctl kern.securelevel
kern.securelevel: -1
On the jail:
$ sysctl kern.securelevel
kern.securelevel: -1
>
> The second is basically
>if (((flags & FWRITE) == 0) || ((flags & FREAD) == 0)) {... return
> EPERM; }
> which isn't happening because of the O_RDWR in the truss output.
>
> The other possibility is that something above the pass driver is doing the
> check. I've not looked at that code path yet, buy you can see if it's
> making it to passopen() with dtrace and checking its return value. I don't
> see anything in how we register the device, though, that would suggest
> filtering it in jails.
>
> Warner
>
> On Sun, Dec 17, 2017 at 12:52 PM, Dan Langille <d...@langille.org> wrote:
>
>> Hello,
>>
>> What suggestions do you have for where I should look next? I'm happy to
>> start installing various builds of FreeBSD in order to track down which
>> commit caused this.
>>
>> I'm trying to access a tape library from within a jail running on a
>> FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0).
>>
>> pass(4) devices (i.e. the tape changer ch0) are not working. This morning
>> I posted to -scsi@: https://lists.freebsd.org/pipermail/freebsd-scsi/2017-
>> December/007608.html
>>
>> The device appears in the jail and has appropriate permissions. This
>> access was granted
>> via /etc/devfs.rules using the same approach I used for FreeBSD 10.3
>>
>> The permissions in the jail:
>>
>> [root@bacula-sd-02 ~]# ls -l /dev/pass7
>> crw--- 1 root operator 0x74 Dec 16 21:52 /dev/pass7
>>
>> The command in the jail:
>>
>> [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status
>> cannot open SCSI device '/dev/pass7' - Operation not permitted
>>
>> Here is the truss output of the command in question:
>> https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe
>>
>> Thank you.
>>
>> --
>> Dan Langille - BSDCan / PGCon
>> d...@langille.org
>>
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cannot access pass device from within jail
> On Dec 17, 2017, at 3:37 PM, Konstantin Belousov <kostik...@gmail.com> wrote: > > On Sun, Dec 17, 2017 at 02:52:12PM -0500, Dan Langille wrote: >> Hello, >> >> What suggestions do you have for where I should look next? I'm happy to >> start installing various builds of FreeBSD in order to track down which >> commit caused this. >> >> I'm trying to access a tape library from within a jail running on a FreeBSD >> 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0). >> >> pass(4) devices (i.e. the tape changer ch0) are not working. This morning I >> posted to -scsi@: >> https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007608.html >> >> The device appears in the jail and has appropriate permissions. This access >> was granted >> via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 >> >> The permissions in the jail: >> >> [root@bacula-sd-02 ~]# ls -l /dev/pass7 >> crw--- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 >> >> The command in the jail: >> >> [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status >> cannot open SCSI device '/dev/pass7' - Operation not permitted >> >> Here is the truss output of the command in question: >> https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe > > Does it work to access the pass device from host using host' /dev ? Yes, it does. see "This command on the host" at https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007610.html > Same question for the host access using the nodes of the jailed devfs mount. I didn't try that, but I will soon. To be clear, does this command on the host look like what you have in mind? mtx -f /usr/jails/bacula-sd-02/dev/pass7 status -- Dan Langille - BSDCan / PGCon d...@langille.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cannot access pass device from within jail
> On Dec 17, 2017, at 3:37 PM, Bjoern A. Zeeb <bzeeb-li...@lists.zabbadoz.net> > wrote: > > On 17 Dec 2017, at 19:52, Dan Langille wrote: > >> Hello, >> >> What suggestions do you have for where I should look next? I'm happy to >> start installing various builds of FreeBSD in order to track down which >> commit caused this. >> >> I'm trying to access a tape library from within a jail running on a FreeBSD >> 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0). >> >> pass(4) devices (i.e. the tape changer ch0) are not working. This morning I >> posted to -scsi@: >> https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007608.html >> >> The device appears in the jail and has appropriate permissions. This access >> was granted >> via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 >> >> The permissions in the jail: >> >> [root@bacula-sd-02 ~]# ls -l /dev/pass7 >> crw--- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 >> >> The command in the jail: >> >> [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status >> cannot open SCSI device '/dev/pass7' - Operation not permitted >> >> Here is the truss output of the command in question: >> https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe > > > You don’t by any chance have a securelevel > 1 set for that jail? On the host: $ sysctl kern.securelevel kern.securelevel: -1 On the jail: $ sysctl kern.securelevel kern.securelevel: -1 Thank you -- Dan Langille - BSDCan / PGCon d...@langille.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
cannot access pass device from within jail
Hello, What suggestions do you have for where I should look next? I'm happy to start installing various builds of FreeBSD in order to track down which commit caused this. I'm trying to access a tape library from within a jail running on a FreeBSD 11.1 host. sa(4) devices are working (e.g. I can rewind nsa0). pass(4) devices (i.e. the tape changer ch0) are not working. This morning I posted to -scsi@: https://lists.freebsd.org/pipermail/freebsd-scsi/2017-December/007608.html The device appears in the jail and has appropriate permissions. This access was granted via /etc/devfs.rules using the same approach I used for FreeBSD 10.3 The permissions in the jail: [root@bacula-sd-02 ~]# ls -l /dev/pass7 crw--- 1 root operator 0x74 Dec 16 21:52 /dev/pass7 The command in the jail: [root@bacula-sd-02 ~]# mtx -f /dev/pass7 status cannot open SCSI device '/dev/pass7' - Operation not permitted Here is the truss output of the command in question: https://gist.github.com/dlangille/b80ee804b8080e1cbf5b5ab67f0bdabe Thank you. -- Dan Langille - BSDCan / PGCon d...@langille.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sa(4) driver changes available for test
On Mar 2, 2015, at 12:26 PM, Kenneth D. Merry k...@freebsd.org wrote: On Mon, Mar 02, 2015 at 11:43:15 -0500, Dan Langille wrote: On Mar 1, 2015, at 9:06 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sun, Mar 01, 2015 at 19:40:40 -0500, Dan Langille wrote: On Mar 1, 2015, at 7:36 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sun, Mar 01, 2015 at 19:28:37 -0500, Dan Langille wrote: On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sun, Mar 01, 2015 at 17:06:24 -0500, Dan Langille wrote: On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt The patches against FreeBSD/head as of SVN revision 278706: http://people.freebsd.org/~ken/sa_changes.20150213.3.txt And (untested) patches against FreeBSD stable/10 as of SVN revision 278721. http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt The intent is to get the tape infrastructure more up to date, so we can support LTFS and more modern tape drives: http://www.ibm.com/systems/storage/tape/ltfs/ I have ported IBM's LTFS Single Drive Edition to FreeBSD. The port depends on the patches linked above. It isn't fully cleaned up and ready for redistribution. If you're interested, though, let me know and I'll tell you when it is ready to go out. You need an IBM LTO-5, LTO-6, TS1140 or TS1150 tape drive. HP drives aren't supported by IBM's LTFS, and older drives don't have the necessary features to support LTFS. The commit message below outlines most of the changes. A few comments: 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. 2. The XML output is similar to what GEOM and CTL do. It would be nice to figure out how to put a standard schema on it so that standard tools could read it. I don't know how feasible that is, since I haven't time to dig into it. If anyone has suggestions on whether that is feasible or advisable, I'd appreciate feedback. 3. I have tested with a reasonable amount of tape hardware (see below for a list), but more testing and feedback would be good. 4. Standard 'mt status' output looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP 5. 'mt status -v' looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP - Tape I/O parameters: Maximum I/O size allowed by driver and controller (maxio): 1081344 bytes Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes Maximum block size supported by tape drive and media (max_blk): 8388608 bytes Minimum block size supported by tape drive and media (min_blk): 1 bytes Block granularity supported by tape drive and media (blk_gran): 0 bytes Maximum possible I/O size (max_effective_iosize): 1081344 bytes # mtx -f /dev/pass0 status Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) Data Transfer Element 0:Empty Data Transfer Element 1:Empty Storage Element 1:Empty Storage Element 2:Empty Storage Element 3:Empty Storage Element 4:Full :VolumeTag=FAI260 Storage Element 5:Full :VolumeTag=FAI261 Storage Element 6:Full :VolumeTag=FAI262 Storage Element 7:Full :VolumeTag=FAI263 Storage Element 8:Empty Storage Element 9:Empty Storage Element 10:Empty It was at this point I spent the next 90 minute trying to get the tape drive out of the tape library to free a stuck tape. Some of this was spent attempting, and failing, to undo a stripped screw. I stopped the attempt when I
Re: sa(4) driver changes available for test
On Mar 2, 2015, at 2:47 PM, Dan Langille d...@langille.org wrote:
On Mar 2, 2015, at 2:07 PM, Dan Langille d...@langille.org wrote:
On Mar 2, 2015, at 12:28 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote:
On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry k...@freebsd.org wrote:
On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote:
On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote:
On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:15:05 -0500, Dan Langille wrote:
On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org
wrote:
On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org
wrote:
I have a fairly large set of changes to the sa(4) driver and
mt(1) driver
that I'm planning to commit in the near future.
A description of the changes is here and below in this message.
If you have tape hardware and the inclination, I'd appreciate
testing and
feedback.
I have a DLT 8000 and an SDLT 220.
I don't have anything running current, but I have a spare machine
which I could use for testing.
Do you see any value is tests with that hardware? I'd be testing
it via Bacula.
disclosure: I'm the sysutils/bacula-* maintainer and a Bacula
committer.
Actually, yes. Bacula is a bit tricky to configure, so your trying
it out
would be helpful if you have the time.
In looking at the manuals for both the SDLT 220 and the DLT 8000,
they both
claim to support long position information for the SCSI READ
POSITION
command.
You can see what I'm talking about by doing:
mt eod
mt status
On my DDS-4 tape drive, this shows:
# mt -f /dev/nsa3 status
Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY
-
Mode Density Blocksize bpi Compression
Current: 0x26:DDS-4 1024 bytes 97000enabled
(DCLZ)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: -1 Calc Record Number: -1
Residual:0 Reported File Number: -1 Reported Record Number: -1
Flags: None
But on an LTO-5, which will give long position information, I get:
[root@doc ~]# mt status
Drive: sa0: IBM ULTRIUM-HH5 E4J1
-
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 enabled (0x1)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: 2 Calc Record Number: -1
Residual:0 Reported File Number: 2 Reported Record Number:
32373
Flags: None
That, in combination with the changes I made to the position
information
code in the driver, mean that even the old MTIOCGET ioctl should
return an
accurate file number at end of data. e.g., on the LTO-5:
[root@doc ~]# mt ostatus
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 0x1
-available modes-
0:0x58:LTO-5 variable 384607 0x1
1:0x58:LTO-5 variable 384607 0x1
2:0x58:LTO-5 variable 384607 0x1
3:0x58:LTO-5 variable 384607 0x1
-
Current Driver State: at rest.
-
File Number: 2 Record Number: -1 Residual Count -1
So the thing to try, in addition to just making sure that Bacula
continues
to work properly, is to try setting this for the tape drive in
bacula-sd.conf:
Hardware End of Medium = yes
It looks like the Bacula tape program (btape) has a test mode, and
it would
be good to run through the tests on one of the tape drives and see
whether
they work, and whether the results are different before and after
the
changes. I'm not sure how to enable the test mode.
I have this in /usr/local/etc/bacula/bacula-sd.conf
Device {
Name= DLT
Description = QUANTUM DLT7000 1624
Media Type = DLT
Archive Device = /dev/nsa1
Autochanger = YES
Drive Index = 0
Offline On Unmount = no
Hardware End of Medium = yes
BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
}
FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a
btape test on this same model.
Here's the test I ran tonight:
[root@cuppy:/usr/home/dan] # btape -c
/usr/local/etc/bacula/bacula-sd.conf /dev/nsa1
Re: sa(4) driver changes available for test
On Mar 2, 2015, at 4:42 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Mon, Mar 02, 2015 at 16:34:34 -0500, Dan Langille wrote:
On Mar 2, 2015, at 2:47 PM, Dan Langille d...@langille.org wrote:
On Mar 2, 2015, at 2:07 PM, Dan Langille d...@langille.org wrote:
On Mar 2, 2015, at 12:28 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote:
On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry k...@freebsd.org wrote:
On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote:
On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote:
On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry k...@freebsd.org
wrote:
On Sun, Mar 01, 2015 at 19:15:05 -0500, Dan Langille wrote:
On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org
wrote:
On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry
k...@freebsd.org wrote:
I have a fairly large set of changes to the sa(4) driver and
mt(1) driver
that I'm planning to commit in the near future.
A description of the changes is here and below in this message.
If you have tape hardware and the inclination, I'd appreciate
testing and
feedback.
I have a DLT 8000 and an SDLT 220.
I don't have anything running current, but I have a spare
machine which I could use for testing.
Do you see any value is tests with that hardware? I'd be testing
it via Bacula.
disclosure: I'm the sysutils/bacula-* maintainer and a Bacula
committer.
Actually, yes. Bacula is a bit tricky to configure, so your
trying it out
would be helpful if you have the time.
In looking at the manuals for both the SDLT 220 and the DLT 8000,
they both
claim to support long position information for the SCSI READ
POSITION
command.
You can see what I'm talking about by doing:
mt eod
mt status
On my DDS-4 tape drive, this shows:
# mt -f /dev/nsa3 status
Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY
-
Mode Density Blocksize bpi Compression
Current: 0x26:DDS-4 1024 bytes 97000enabled
(DCLZ)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: -1 Calc Record Number:
-1
Residual:0 Reported File Number: -1 Reported Record Number:
-1
Flags: None
But on an LTO-5, which will give long position information, I get:
[root@doc ~]# mt status
Drive: sa0: IBM ULTRIUM-HH5 E4J1
-
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 enabled
(0x1)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: 2 Calc Record Number:
-1
Residual:0 Reported File Number: 2 Reported Record Number:
32373
Flags: None
That, in combination with the changes I made to the position
information
code in the driver, mean that even the old MTIOCGET ioctl should
return an
accurate file number at end of data. e.g., on the LTO-5:
[root@doc ~]# mt ostatus
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 0x1
-available modes-
0:0x58:LTO-5 variable 384607 0x1
1:0x58:LTO-5 variable 384607 0x1
2:0x58:LTO-5 variable 384607 0x1
3:0x58:LTO-5 variable 384607 0x1
-
Current Driver State: at rest.
-
File Number: 2 Record Number: -1 Residual Count -1
So the thing to try, in addition to just making sure that Bacula
continues
to work properly, is to try setting this for the tape drive in
bacula-sd.conf:
Hardware End of Medium = yes
It looks like the Bacula tape program (btape) has a test mode,
and it would
be good to run through the tests on one of the tape drives and
see whether
they work, and whether the results are different before and after
the
changes. I'm not sure how to enable the test mode.
I have this in /usr/local/etc/bacula/bacula-sd.conf
Device {
Name= DLT
Description = QUANTUM DLT7000 1624
Media Type = DLT
Archive Device = /dev/nsa1
Autochanger = YES
Drive Index = 0
Offline On Unmount = no
Hardware End of Medium = yes
BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
}
FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has
a btape test on this same model.
Here's the test I ran
Re: sa(4) driver changes available for test
On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote:
On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:15:05 -0500, Dan Langille wrote:
On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote:
I have a fairly large set of changes to the sa(4) driver and mt(1)
driver
that I'm planning to commit in the near future.
A description of the changes is here and below in this message.
If you have tape hardware and the inclination, I'd appreciate testing
and
feedback.
I have a DLT 8000 and an SDLT 220.
I don't have anything running current, but I have a spare machine which
I could use for testing.
Do you see any value is tests with that hardware? I'd be testing it via
Bacula.
disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer.
Actually, yes. Bacula is a bit tricky to configure, so your trying it out
would be helpful if you have the time.
In looking at the manuals for both the SDLT 220 and the DLT 8000, they
both
claim to support long position information for the SCSI READ POSITION
command.
You can see what I'm talking about by doing:
mt eod
mt status
On my DDS-4 tape drive, this shows:
# mt -f /dev/nsa3 status
Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY
-
Mode Density Blocksize bpi Compression
Current: 0x26:DDS-4 1024 bytes 97000enabled (DCLZ)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: -1 Calc Record Number: -1
Residual:0 Reported File Number: -1 Reported Record Number: -1
Flags: None
But on an LTO-5, which will give long position information, I get:
[root@doc ~]# mt status
Drive: sa0: IBM ULTRIUM-HH5 E4J1
-
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 enabled (0x1)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: 2 Calc Record Number: -1
Residual:0 Reported File Number: 2 Reported Record Number: 32373
Flags: None
That, in combination with the changes I made to the position information
code in the driver, mean that even the old MTIOCGET ioctl should return an
accurate file number at end of data. e.g., on the LTO-5:
[root@doc ~]# mt ostatus
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 0x1
-available modes-
0:0x58:LTO-5 variable 384607 0x1
1:0x58:LTO-5 variable 384607 0x1
2:0x58:LTO-5 variable 384607 0x1
3:0x58:LTO-5 variable 384607 0x1
-
Current Driver State: at rest.
-
File Number: 2 Record Number: -1 Residual Count -1
So the thing to try, in addition to just making sure that Bacula continues
to work properly, is to try setting this for the tape drive in
bacula-sd.conf:
Hardware End of Medium = yes
It looks like the Bacula tape program (btape) has a test mode, and it
would
be good to run through the tests on one of the tape drives and see whether
they work, and whether the results are different before and after the
changes. I'm not sure how to enable the test mode.
I have this in /usr/local/etc/bacula/bacula-sd.conf
Device {
Name= DLT
Description = QUANTUM DLT7000 1624
Media Type = DLT
Archive Device = /dev/nsa1
Autochanger = YES
Drive Index = 0
Offline On Unmount = no
Hardware End of Medium = yes
BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
}
FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a btape
test on this same model.
Here's the test I ran tonight:
[root@cuppy:/usr/home/dan] # btape -c /usr/local/etc/bacula/bacula-sd.conf
/dev/nsa1
Tape block granularity is 1024 bytes.
btape: butil.c:287-0 Using device: /dev/nsa1 for writing.
btape: btape.c:469-0 open device DLT (/dev/nsa1): OK
*test
=== Write, rewind, and re-read test ===
I'm going to write 1 records and an EOF
then write 1 records and an EOF, then rewind,
and re-read the data to verify that it is correct.
This is an *essential* feature
Re: sa(4) driver changes available for test
On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry k...@freebsd.org wrote:
On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote:
On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote:
On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:15:05 -0500, Dan Langille wrote:
On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org
wrote:
I have a fairly large set of changes to the sa(4) driver and mt(1)
driver
that I'm planning to commit in the near future.
A description of the changes is here and below in this message.
If you have tape hardware and the inclination, I'd appreciate testing
and
feedback.
I have a DLT 8000 and an SDLT 220.
I don't have anything running current, but I have a spare machine
which I could use for testing.
Do you see any value is tests with that hardware? I'd be testing it
via Bacula.
disclosure: I'm the sysutils/bacula-* maintainer and a Bacula
committer.
Actually, yes. Bacula is a bit tricky to configure, so your trying it
out
would be helpful if you have the time.
In looking at the manuals for both the SDLT 220 and the DLT 8000, they
both
claim to support long position information for the SCSI READ POSITION
command.
You can see what I'm talking about by doing:
mt eod
mt status
On my DDS-4 tape drive, this shows:
# mt -f /dev/nsa3 status
Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY
-
Mode Density Blocksize bpi Compression
Current: 0x26:DDS-4 1024 bytes 97000enabled (DCLZ)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: -1 Calc Record Number: -1
Residual:0 Reported File Number: -1 Reported Record Number: -1
Flags: None
But on an LTO-5, which will give long position information, I get:
[root@doc ~]# mt status
Drive: sa0: IBM ULTRIUM-HH5 E4J1
-
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 enabled (0x1)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: 2 Calc Record Number: -1
Residual:0 Reported File Number: 2 Reported Record Number: 32373
Flags: None
That, in combination with the changes I made to the position information
code in the driver, mean that even the old MTIOCGET ioctl should return
an
accurate file number at end of data. e.g., on the LTO-5:
[root@doc ~]# mt ostatus
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 0x1
-available modes-
0:0x58:LTO-5 variable 384607 0x1
1:0x58:LTO-5 variable 384607 0x1
2:0x58:LTO-5 variable 384607 0x1
3:0x58:LTO-5 variable 384607 0x1
-
Current Driver State: at rest.
-
File Number: 2 Record Number: -1 Residual Count -1
So the thing to try, in addition to just making sure that Bacula
continues
to work properly, is to try setting this for the tape drive in
bacula-sd.conf:
Hardware End of Medium = yes
It looks like the Bacula tape program (btape) has a test mode, and it
would
be good to run through the tests on one of the tape drives and see
whether
they work, and whether the results are different before and after the
changes. I'm not sure how to enable the test mode.
I have this in /usr/local/etc/bacula/bacula-sd.conf
Device {
Name= DLT
Description = QUANTUM DLT7000 1624
Media Type = DLT
Archive Device = /dev/nsa1
Autochanger = YES
Drive Index = 0
Offline On Unmount = no
Hardware End of Medium = yes
BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
}
FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a
btape test on this same model.
Here's the test I ran tonight:
[root@cuppy:/usr/home/dan] # btape -c
/usr/local/etc/bacula/bacula-sd.conf /dev/nsa1
Tape block granularity is 1024 bytes.
btape: butil.c:287-0 Using device: /dev/nsa1 for writing.
btape: btape.c:469-0 open device DLT (/dev/nsa1): OK
*test
=== Write, rewind, and re-read test ===
I'm going to write 1 records
Re: sa(4) driver changes available for test
On Mar 1, 2015, at 9:06 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sun, Mar 01, 2015 at 19:40:40 -0500, Dan Langille wrote: On Mar 1, 2015, at 7:36 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sun, Mar 01, 2015 at 19:28:37 -0500, Dan Langille wrote: On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sun, Mar 01, 2015 at 17:06:24 -0500, Dan Langille wrote: On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt The patches against FreeBSD/head as of SVN revision 278706: http://people.freebsd.org/~ken/sa_changes.20150213.3.txt And (untested) patches against FreeBSD stable/10 as of SVN revision 278721. http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt The intent is to get the tape infrastructure more up to date, so we can support LTFS and more modern tape drives: http://www.ibm.com/systems/storage/tape/ltfs/ I have ported IBM's LTFS Single Drive Edition to FreeBSD. The port depends on the patches linked above. It isn't fully cleaned up and ready for redistribution. If you're interested, though, let me know and I'll tell you when it is ready to go out. You need an IBM LTO-5, LTO-6, TS1140 or TS1150 tape drive. HP drives aren't supported by IBM's LTFS, and older drives don't have the necessary features to support LTFS. The commit message below outlines most of the changes. A few comments: 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. 2. The XML output is similar to what GEOM and CTL do. It would be nice to figure out how to put a standard schema on it so that standard tools could read it. I don't know how feasible that is, since I haven't time to dig into it. If anyone has suggestions on whether that is feasible or advisable, I'd appreciate feedback. 3. I have tested with a reasonable amount of tape hardware (see below for a list), but more testing and feedback would be good. 4. Standard 'mt status' output looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP 5. 'mt status -v' looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP - Tape I/O parameters: Maximum I/O size allowed by driver and controller (maxio): 1081344 bytes Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes Maximum block size supported by tape drive and media (max_blk): 8388608 bytes Minimum block size supported by tape drive and media (min_blk): 1 bytes Block granularity supported by tape drive and media (blk_gran): 0 bytes Maximum possible I/O size (max_effective_iosize): 1081344 bytes # mtx -f /dev/pass0 status Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) Data Transfer Element 0:Empty Data Transfer Element 1:Empty Storage Element 1:Empty Storage Element 2:Empty Storage Element 3:Empty Storage Element 4:Full :VolumeTag=FAI260 Storage Element 5:Full :VolumeTag=FAI261 Storage Element 6:Full :VolumeTag=FAI262 Storage Element 7:Full :VolumeTag=FAI263 Storage Element 8:Empty Storage Element 9:Empty Storage Element 10:Empty It was at this point I spent the next 90 minute trying to get the tape drive out of the tape library to free a stuck tape. Some of this was spent attempting, and failing, to undo a stripped screw. I stopped the attempt when I noticed the screw did need to be removed. :/ Thanks for all of the effort! Looks like it is paying off! :) When I do this command, I hear
Re: sa(4) driver changes available for test
On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. This came to me today via the Bacula mailing lists. http://marc.info/?l=bacula-usersm=142531236722693w=2 As far as I can tell ltfs support on linux sits on top of the standard mt-st stuff \ as a userspace (fuse) filesystem I'd hope it's much the same with BSD. Removing the standard interface would be \ counterproductive overall Can you answer that and I'll relay please? — Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
On Mar 2, 2015, at 12:28 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote:
On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry k...@freebsd.org wrote:
On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote:
On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote:
On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:15:05 -0500, Dan Langille wrote:
On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org
wrote:
On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org
wrote:
I have a fairly large set of changes to the sa(4) driver and mt(1)
driver
that I'm planning to commit in the near future.
A description of the changes is here and below in this message.
If you have tape hardware and the inclination, I'd appreciate
testing and
feedback.
I have a DLT 8000 and an SDLT 220.
I don't have anything running current, but I have a spare machine
which I could use for testing.
Do you see any value is tests with that hardware? I'd be testing it
via Bacula.
disclosure: I'm the sysutils/bacula-* maintainer and a Bacula
committer.
Actually, yes. Bacula is a bit tricky to configure, so your trying
it out
would be helpful if you have the time.
In looking at the manuals for both the SDLT 220 and the DLT 8000,
they both
claim to support long position information for the SCSI READ POSITION
command.
You can see what I'm talking about by doing:
mt eod
mt status
On my DDS-4 tape drive, this shows:
# mt -f /dev/nsa3 status
Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY
-
Mode Density Blocksize bpi Compression
Current: 0x26:DDS-4 1024 bytes 97000enabled (DCLZ)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: -1 Calc Record Number: -1
Residual:0 Reported File Number: -1 Reported Record Number: -1
Flags: None
But on an LTO-5, which will give long position information, I get:
[root@doc ~]# mt status
Drive: sa0: IBM ULTRIUM-HH5 E4J1
-
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 enabled (0x1)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: 2 Calc Record Number: -1
Residual:0 Reported File Number: 2 Reported Record Number:
32373
Flags: None
That, in combination with the changes I made to the position
information
code in the driver, mean that even the old MTIOCGET ioctl should
return an
accurate file number at end of data. e.g., on the LTO-5:
[root@doc ~]# mt ostatus
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 0x1
-available modes-
0:0x58:LTO-5 variable 384607 0x1
1:0x58:LTO-5 variable 384607 0x1
2:0x58:LTO-5 variable 384607 0x1
3:0x58:LTO-5 variable 384607 0x1
-
Current Driver State: at rest.
-
File Number: 2 Record Number: -1 Residual Count -1
So the thing to try, in addition to just making sure that Bacula
continues
to work properly, is to try setting this for the tape drive in
bacula-sd.conf:
Hardware End of Medium = yes
It looks like the Bacula tape program (btape) has a test mode, and it
would
be good to run through the tests on one of the tape drives and see
whether
they work, and whether the results are different before and after the
changes. I'm not sure how to enable the test mode.
I have this in /usr/local/etc/bacula/bacula-sd.conf
Device {
Name= DLT
Description = QUANTUM DLT7000 1624
Media Type = DLT
Archive Device = /dev/nsa1
Autochanger = YES
Drive Index = 0
Offline On Unmount = no
Hardware End of Medium = yes
BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
}
FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a
btape test on this same model.
Here's the test I ran tonight:
[root@cuppy:/usr/home/dan] # btape -c
/usr/local/etc/bacula/bacula-sd.conf /dev/nsa1
Tape block granularity is 1024 bytes.
btape: butil.c:287-0 Using device: /dev/nsa1 for writing
Re: sa(4) driver changes available for test
On Mar 2, 2015, at 2:07 PM, Dan Langille d...@langille.org wrote:
On Mar 2, 2015, at 12:28 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote:
On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry k...@freebsd.org wrote:
On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote:
On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote:
On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:15:05 -0500, Dan Langille wrote:
On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org
wrote:
On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org
wrote:
I have a fairly large set of changes to the sa(4) driver and mt(1)
driver
that I'm planning to commit in the near future.
A description of the changes is here and below in this message.
If you have tape hardware and the inclination, I'd appreciate
testing and
feedback.
I have a DLT 8000 and an SDLT 220.
I don't have anything running current, but I have a spare machine
which I could use for testing.
Do you see any value is tests with that hardware? I'd be testing it
via Bacula.
disclosure: I'm the sysutils/bacula-* maintainer and a Bacula
committer.
Actually, yes. Bacula is a bit tricky to configure, so your trying
it out
would be helpful if you have the time.
In looking at the manuals for both the SDLT 220 and the DLT 8000,
they both
claim to support long position information for the SCSI READ POSITION
command.
You can see what I'm talking about by doing:
mt eod
mt status
On my DDS-4 tape drive, this shows:
# mt -f /dev/nsa3 status
Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY
-
Mode Density Blocksize bpi Compression
Current: 0x26:DDS-4 1024 bytes 97000enabled (DCLZ)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: -1 Calc Record Number: -1
Residual:0 Reported File Number: -1 Reported Record Number: -1
Flags: None
But on an LTO-5, which will give long position information, I get:
[root@doc ~]# mt status
Drive: sa0: IBM ULTRIUM-HH5 E4J1
-
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 enabled (0x1)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: 2 Calc Record Number: -1
Residual:0 Reported File Number: 2 Reported Record Number:
32373
Flags: None
That, in combination with the changes I made to the position
information
code in the driver, mean that even the old MTIOCGET ioctl should
return an
accurate file number at end of data. e.g., on the LTO-5:
[root@doc ~]# mt ostatus
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 0x1
-available modes-
0:0x58:LTO-5 variable 384607 0x1
1:0x58:LTO-5 variable 384607 0x1
2:0x58:LTO-5 variable 384607 0x1
3:0x58:LTO-5 variable 384607 0x1
-
Current Driver State: at rest.
-
File Number: 2 Record Number: -1 Residual Count -1
So the thing to try, in addition to just making sure that Bacula
continues
to work properly, is to try setting this for the tape drive in
bacula-sd.conf:
Hardware End of Medium = yes
It looks like the Bacula tape program (btape) has a test mode, and
it would
be good to run through the tests on one of the tape drives and see
whether
they work, and whether the results are different before and after the
changes. I'm not sure how to enable the test mode.
I have this in /usr/local/etc/bacula/bacula-sd.conf
Device {
Name= DLT
Description = QUANTUM DLT7000 1624
Media Type = DLT
Archive Device = /dev/nsa1
Autochanger = YES
Drive Index = 0
Offline On Unmount = no
Hardware End of Medium = yes
BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
}
FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a
btape test on this same model.
Here's the test I ran tonight:
[root@cuppy:/usr/home/dan] # btape -c
/usr/local/etc/bacula/bacula-sd.conf /dev/nsa1
Tape block granularity
Re: sa(4) driver changes available for test
On Mar 1, 2015, at 7:36 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sun, Mar 01, 2015 at 19:28:37 -0500, Dan Langille wrote: On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sun, Mar 01, 2015 at 17:06:24 -0500, Dan Langille wrote: On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt The patches against FreeBSD/head as of SVN revision 278706: http://people.freebsd.org/~ken/sa_changes.20150213.3.txt And (untested) patches against FreeBSD stable/10 as of SVN revision 278721. http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt The intent is to get the tape infrastructure more up to date, so we can support LTFS and more modern tape drives: http://www.ibm.com/systems/storage/tape/ltfs/ I have ported IBM's LTFS Single Drive Edition to FreeBSD. The port depends on the patches linked above. It isn't fully cleaned up and ready for redistribution. If you're interested, though, let me know and I'll tell you when it is ready to go out. You need an IBM LTO-5, LTO-6, TS1140 or TS1150 tape drive. HP drives aren't supported by IBM's LTFS, and older drives don't have the necessary features to support LTFS. The commit message below outlines most of the changes. A few comments: 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. 2. The XML output is similar to what GEOM and CTL do. It would be nice to figure out how to put a standard schema on it so that standard tools could read it. I don't know how feasible that is, since I haven't time to dig into it. If anyone has suggestions on whether that is feasible or advisable, I'd appreciate feedback. 3. I have tested with a reasonable amount of tape hardware (see below for a list), but more testing and feedback would be good. 4. Standard 'mt status' output looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP 5. 'mt status -v' looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP - Tape I/O parameters: Maximum I/O size allowed by driver and controller (maxio): 1081344 bytes Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes Maximum block size supported by tape drive and media (max_blk): 8388608 bytes Minimum block size supported by tape drive and media (min_blk): 1 bytes Block granularity supported by tape drive and media (blk_gran): 0 bytes Maximum possible I/O size (max_effective_iosize): 1081344 bytes # mtx -f /dev/pass0 status Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) Data Transfer Element 0:Empty Data Transfer Element 1:Empty Storage Element 1:Empty Storage Element 2:Empty Storage Element 3:Empty Storage Element 4:Full :VolumeTag=FAI260 Storage Element 5:Full :VolumeTag=FAI261 Storage Element 6:Full :VolumeTag=FAI262 Storage Element 7:Full :VolumeTag=FAI263 Storage Element 8:Empty Storage Element 9:Empty Storage Element 10:Empty It was at this point I spent the next 90 minute trying to get the tape drive out of the tape library to free a stuck tape. Some of this was spent attempting, and failing, to undo a stripped screw. I stopped the attempt when I noticed the screw did need to be removed. :/ Thanks for all of the effort! Looks like it is paying off! :) When I do this command, I hear the drive move a bit, to read the tape: # mt -f /dev/nsa1 status Drive: sa1: DEC TZ89 (C) DEC 2561 Serial Number: CXA09S1340
Re: sa(4) driver changes available for test
'mt setspos' and 'mt sethpos' commands. 'mt locate' implements all of the functionality of the MTIOCEXTLOCATE ioctl, and allows the user to change the logical position of the tape drive in a number of ways. (Partition, block number, file number, set mark number, end of data.) The immediate bit and the explicit address bits are implemented, but not documented in the man page. Add a new 'mt weofi' command to use the new MTWEOFI ioctl. This allows the user to ask the drive to write a filemark without waiting around for the operation to complete. Add a new 'mt getdensity' command that gets the XML-based tape drive density report from the sa(4) driver and displays it. This uses the SCSI REPORT DENSITY SUPPORT command to get comprehensive information from the tape drive about what formats it is able to read and write. Add a new 'mt protect' command that allows getting and setting tape drive protection information. The protection information is a CRC tacked on to the end of every read/write from and to the tape drive. Sponsored by: Spectra Logic MFC after:1 month Thanks, Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-s...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-scsi To unsubscribe, send any mail to freebsd-scsi-unsubscr...@freebsd.org — Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote:
I have a fairly large set of changes to the sa(4) driver and mt(1) driver
that I'm planning to commit in the near future.
A description of the changes is here and below in this message.
If you have tape hardware and the inclination, I'd appreciate testing and
feedback.
I have a DLT 8000 and an SDLT 220.
I don't have anything running current, but I have a spare machine which I
could use for testing.
Do you see any value is tests with that hardware? I'd be testing it via
Bacula.
disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer.
Actually, yes. Bacula is a bit tricky to configure, so your trying it out
would be helpful if you have the time.
In looking at the manuals for both the SDLT 220 and the DLT 8000, they both
claim to support long position information for the SCSI READ POSITION
command.
You can see what I'm talking about by doing:
mt eod
mt status
On my DDS-4 tape drive, this shows:
# mt -f /dev/nsa3 status
Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY
-
Mode Density Blocksize bpi Compression
Current: 0x26:DDS-4 1024 bytes 97000enabled (DCLZ)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: -1 Calc Record Number: -1
Residual:0 Reported File Number: -1 Reported Record Number: -1
Flags: None
But on an LTO-5, which will give long position information, I get:
[root@doc ~]# mt status
Drive: sa0: IBM ULTRIUM-HH5 E4J1
-
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 enabled (0x1)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: 2 Calc Record Number: -1
Residual:0 Reported File Number: 2 Reported Record Number: 32373
Flags: None
That, in combination with the changes I made to the position information
code in the driver, mean that even the old MTIOCGET ioctl should return an
accurate file number at end of data. e.g., on the LTO-5:
[root@doc ~]# mt ostatus
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 0x1
-available modes-
0:0x58:LTO-5 variable 384607 0x1
1:0x58:LTO-5 variable 384607 0x1
2:0x58:LTO-5 variable 384607 0x1
3:0x58:LTO-5 variable 384607 0x1
-
Current Driver State: at rest.
-
File Number: 2 Record Number: -1 Residual Count -1
So the thing to try, in addition to just making sure that Bacula continues
to work properly, is to try setting this for the tape drive in
bacula-sd.conf:
Hardware End of Medium = yes
It looks like the Bacula tape program (btape) has a test mode, and it would
be good to run through the tests on one of the tape drives and see whether
they work, and whether the results are different before and after the
changes. I'm not sure how to enable the test mode.
I have this in /usr/local/etc/bacula/bacula-sd.conf
Device {
Name= DLT
Description = QUANTUM DLT7000 1624
Media Type = DLT
Archive Device = /dev/nsa1
Autochanger = YES
Drive Index = 0
Offline On Unmount = no
Hardware End of Medium = yes
BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
}
FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a btape test
on this same model.
Here's the test I ran tonight:
[root@cuppy:/usr/home/dan] # btape -c /usr/local/etc/bacula/bacula-sd.conf
/dev/nsa1
Tape block granularity is 1024 bytes.
btape: butil.c:287-0 Using device: /dev/nsa1 for writing.
btape: btape.c:469-0 open device DLT (/dev/nsa1): OK
*test
=== Write, rewind, and re-read test ===
I'm going to write 1 records and an EOF
then write 1 records and an EOF, then rewind,
and re-read the data to verify that it is correct.
This is an *essential* feature ...
btape: btape.c:1152-0 Wrote 1 blocks of 64412 bytes.
btape: btape.c:604-0 Wrote 1 EOF to DLT (/dev/nsa1)
btape: btape.c:1168-0 Wrote 1 blocks of 64412 bytes.
btape: btape.c:604-0 Wrote 1 EOF to DLT (/dev/nsa1)
btape: btape.c:604-0 Wrote 1 EOF to DLT (/dev/nsa1)
btape: btape.c:1210-0
Re: sa(4) driver changes available for test
On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sun, Mar 01, 2015 at 17:06:24 -0500, Dan Langille wrote: On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt The patches against FreeBSD/head as of SVN revision 278706: http://people.freebsd.org/~ken/sa_changes.20150213.3.txt And (untested) patches against FreeBSD stable/10 as of SVN revision 278721. http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt The intent is to get the tape infrastructure more up to date, so we can support LTFS and more modern tape drives: http://www.ibm.com/systems/storage/tape/ltfs/ I have ported IBM's LTFS Single Drive Edition to FreeBSD. The port depends on the patches linked above. It isn't fully cleaned up and ready for redistribution. If you're interested, though, let me know and I'll tell you when it is ready to go out. You need an IBM LTO-5, LTO-6, TS1140 or TS1150 tape drive. HP drives aren't supported by IBM's LTFS, and older drives don't have the necessary features to support LTFS. The commit message below outlines most of the changes. A few comments: 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. 2. The XML output is similar to what GEOM and CTL do. It would be nice to figure out how to put a standard schema on it so that standard tools could read it. I don't know how feasible that is, since I haven't time to dig into it. If anyone has suggestions on whether that is feasible or advisable, I'd appreciate feedback. 3. I have tested with a reasonable amount of tape hardware (see below for a list), but more testing and feedback would be good. 4. Standard 'mt status' output looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP 5. 'mt status -v' looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP - Tape I/O parameters: Maximum I/O size allowed by driver and controller (maxio): 1081344 bytes Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes Maximum block size supported by tape drive and media (max_blk): 8388608 bytes Minimum block size supported by tape drive and media (min_blk): 1 bytes Block granularity supported by tape drive and media (blk_gran): 0 bytes Maximum possible I/O size (max_effective_iosize): 1081344 bytes # mtx -f /dev/pass0 status Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) Data Transfer Element 0:Empty Data Transfer Element 1:Empty Storage Element 1:Empty Storage Element 2:Empty Storage Element 3:Empty Storage Element 4:Full :VolumeTag=FAI260 Storage Element 5:Full :VolumeTag=FAI261 Storage Element 6:Full :VolumeTag=FAI262 Storage Element 7:Full :VolumeTag=FAI263 Storage Element 8:Empty Storage Element 9:Empty Storage Element 10:Empty It was at this point I spent the next 90 minute trying to get the tape drive out of the tape library to free a stuck tape. Some of this was spent attempting, and failing, to undo a stripped screw. I stopped the attempt when I noticed the screw did need to be removed. :/ Thanks for all of the effort! Looks like it is paying off! :) When I do this command, I hear the drive move a bit, to read the tape: # mt -f /dev/nsa1 status Drive: sa1: DEC TZ89 (C) DEC 2561 Serial Number: CXA09S1340 - Mode DensityBlocksize bpi Compression Current
Re: sa(4) driver changes available for test
On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sun, Mar 01, 2015 at 19:15:05 -0500, Dan Langille wrote:
On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org wrote:
On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote:
I have a fairly large set of changes to the sa(4) driver and mt(1) driver
that I'm planning to commit in the near future.
A description of the changes is here and below in this message.
If you have tape hardware and the inclination, I'd appreciate testing and
feedback.
I have a DLT 8000 and an SDLT 220.
I don't have anything running current, but I have a spare machine which I
could use for testing.
Do you see any value is tests with that hardware? I'd be testing it via
Bacula.
disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer.
Actually, yes. Bacula is a bit tricky to configure, so your trying it out
would be helpful if you have the time.
In looking at the manuals for both the SDLT 220 and the DLT 8000, they both
claim to support long position information for the SCSI READ POSITION
command.
You can see what I'm talking about by doing:
mt eod
mt status
On my DDS-4 tape drive, this shows:
# mt -f /dev/nsa3 status
Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY
-
Mode Density Blocksize bpi Compression
Current: 0x26:DDS-4 1024 bytes 97000enabled (DCLZ)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: -1 Calc Record Number: -1
Residual:0 Reported File Number: -1 Reported Record Number: -1
Flags: None
But on an LTO-5, which will give long position information, I get:
[root@doc ~]# mt status
Drive: sa0: IBM ULTRIUM-HH5 E4J1
-
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 enabled (0x1)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: 2 Calc Record Number: -1
Residual:0 Reported File Number: 2 Reported Record Number: 32373
Flags: None
That, in combination with the changes I made to the position information
code in the driver, mean that even the old MTIOCGET ioctl should return an
accurate file number at end of data. e.g., on the LTO-5:
[root@doc ~]# mt ostatus
Mode Density Blocksize bpi Compression
Current: 0x58:LTO-5 variable 384607 0x1
-available modes-
0:0x58:LTO-5 variable 384607 0x1
1:0x58:LTO-5 variable 384607 0x1
2:0x58:LTO-5 variable 384607 0x1
3:0x58:LTO-5 variable 384607 0x1
-
Current Driver State: at rest.
-
File Number: 2 Record Number: -1 Residual Count -1
So the thing to try, in addition to just making sure that Bacula continues
to work properly, is to try setting this for the tape drive in
bacula-sd.conf:
Hardware End of Medium = yes
It looks like the Bacula tape program (btape) has a test mode, and it would
be good to run through the tests on one of the tape drives and see whether
they work, and whether the results are different before and after the
changes. I'm not sure how to enable the test mode.
I have this in /usr/local/etc/bacula/bacula-sd.conf
Device {
Name= DLT
Description = QUANTUM DLT7000 1624
Media Type = DLT
Archive Device = /dev/nsa1
Autochanger = YES
Drive Index = 0
Offline On Unmount = no
Hardware End of Medium = yes
BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
}
FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a btape
test on this same model.
Here's the test I ran tonight:
[root@cuppy:/usr/home/dan] # btape -c /usr/local/etc/bacula/bacula-sd.conf
/dev/nsa1
Tape block granularity is 1024 bytes.
btape: butil.c:287-0 Using device: /dev/nsa1 for writing.
btape: btape.c:469-0 open device DLT (/dev/nsa1): OK
*test
=== Write, rewind, and re-read test ===
I'm going to write 1 records and an EOF
then write 1 records and an EOF, then rewind,
and re-read the data to verify that it is correct.
This is an *essential* feature ...
btape: btape.c:1152-0 Wrote 1 blocks of 64412 bytes.
btape: btape.c:604-0 Wrote 1 EOF to DLT (/dev/nsa1)
btape: btape.c
Re: sa(4) driver changes available for test
On Feb 28, 2015, at 6:42 PM, Dan Langille d...@langille.org wrote: On Feb 28, 2015, at 6:15 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote: On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry k...@freebsd.org wrote: I have updated the patches. I have removed the XPT_DEV_ADVINFO changes from the patches to head, since I committed those separately. I have (hopefully) fixed the build for the stable/10 patches by MFCing dependencies. (One of them mav did for me, thanks!) Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt I have current installed and running with Bacula, but I have not tried the tape drive yet. Thanks for all your work on this! It seems like your changes are in there from about 5 days ago. Yes, that is correct. Having solved my server hardware issues, I'm now having issues with the autochanger mechanism of the tape library. Does it work with chio(1)? Does it look like hardware or software? (If it is software, I can help with that.) Hardware. The screw drive for the tape robot is sticky. It can be moved by hand, but the motor in this DL 891 cannot. It might need lube. It was suspect last time I used it. Worst case, I will remove ins of the two DLT 8000 tape drives and load tapes manually. A bit of lube, and we have POST: https://twitter.com/DLangille/status/572117570997919744 More, soon. — Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
On Feb 28, 2015, at 1:47 AM, Kenneth D. Merry k...@freebsd.org wrote: On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote: On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. I have a DLT 8000 and an SDLT 220. I don't have anything running current, but I have a spare machine which I could use for testing. Do you see any value is tests with that hardware? I'd be testing it via Bacula. disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer. Actually, yes. Bacula is a bit tricky to configure, so your trying it out would be helpful if you have the time. I have been unable to test yet. I've encountered time and hardware issues. I know how that goes! (On both counts.) Hardware issues fixed. Now upgrading that zfsroot box from 9.2 to 10.1 RELEASE. sudo freebsd-update -r 10.1-RELEASE upgrade Then I'll grab sources, apply your 10 STABLE patches, and build world. I may be able to try tomorrow. So I have tested building it and it does build at least. If you're able to figure out some of the answers below, that would be great! In looking at the manuals for both the SDLT 220 and the DLT 8000, they both claim to support long position information for the SCSI READ POSITION command. You can see what I'm talking about by doing: mt eod mt status On my DDS-4 tape drive, this shows: # mt -f /dev/nsa3 status Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY - Mode Density Blocksize bpi Compression Current: 0x26:DDS-4 1024 bytes 97000enabled (DCLZ) - Current Driver State: at rest. - Partition: 0 Calc File Number: -1 Calc Record Number: -1 Residual:0 Reported File Number: -1 Reported Record Number: -1 Flags: None But on an LTO-5, which will give long position information, I get: [root@doc ~]# mt status Drive: sa0: IBM ULTRIUM-HH5 E4J1 - Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 enabled (0x1) - Current Driver State: at rest. - Partition: 0 Calc File Number: 2 Calc Record Number: -1 Residual:0 Reported File Number: 2 Reported Record Number: 32373 Flags: None That, in combination with the changes I made to the position information code in the driver, mean that even the old MTIOCGET ioctl should return an accurate file number at end of data. e.g., on the LTO-5: [root@doc ~]# mt ostatus Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 0x1 -available modes- 0:0x58:LTO-5 variable 384607 0x1 1:0x58:LTO-5 variable 384607 0x1 2:0x58:LTO-5 variable 384607 0x1 3:0x58:LTO-5 variable 384607 0x1 - Current Driver State: at rest. - File Number: 2 Record Number: -1 Residual Count -1 So the thing to try, in addition to just making sure that Bacula continues to work properly, is to try setting this for the tape drive in bacula-sd.conf: Hardware End of Medium = yes It looks like the Bacula tape program (btape) has a test mode, and it would be good to run through the tests on one of the tape drives and see whether they work, and whether the results are different before and after the changes. I'm not sure how to enable the test mode. I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL. Thanks! If there are additional features they would like out of the tape driver, I'm happy to talk about it. (Or help if they'd like to use the new status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.) Ken -- Kenneth Merry k...@freebsd.org ? Dan Langille http://langille.org/ Ken -- Kenneth Merry k...@freebsd.org — Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry k...@freebsd.org wrote: I have updated the patches. I have removed the XPT_DEV_ADVINFO changes from the patches to head, since I committed those separately. I have (hopefully) fixed the build for the stable/10 patches by MFCing dependencies. (One of them mav did for me, thanks!) Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt I have current installed and running with Bacula, but I have not tried the tape drive yet. It seems like your changes are in there from about 5 days ago. Having solved my server hardware issues, I'm now having issues with the autochanger mechanism of the tape library. — Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
On Feb 28, 2015, at 6:15 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote: On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry k...@freebsd.org wrote: I have updated the patches. I have removed the XPT_DEV_ADVINFO changes from the patches to head, since I committed those separately. I have (hopefully) fixed the build for the stable/10 patches by MFCing dependencies. (One of them mav did for me, thanks!) Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt I have current installed and running with Bacula, but I have not tried the tape drive yet. Thanks for all your work on this! It seems like your changes are in there from about 5 days ago. Yes, that is correct. Having solved my server hardware issues, I'm now having issues with the autochanger mechanism of the tape library. Does it work with chio(1)? Does it look like hardware or software? (If it is software, I can help with that.) Hardware. The screw drive for the tape robot is sticky. It can be moved by hand, but the motor in this DL 891 cannot. It might need lube. It was suspect last time I used it. Worst case, I will remove ins of the two DLT 8000 tape drives and load tapes manually. -- Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
. This should be a no-op for everything except the control device, since we don't allow more than one open on non-control devices. However, since we do allow multiple opens on the control device, the combination of the open count and the D_TRACKCLOSE flag should result in an accurate peripheral driver reference count, and an accurate open count. The accurate open count allows us to release all peripheral driver references that are the result of open contexts once we get the callback from devfs. sys/sys/mtio.h: Add a number of new mt(4) ioctls and the requisite data structures. None of the existing interfaces been removed or changed. This includes definitions for the following new ioctls: MTIOCRBLIM /* get block limits */ MTIOCEXTLOCATE /* seek to position */ MTIOCEXTGET /* get tape status */ MTIOCPARAMGET /* get tape params */ MTIOCPARAMSET /* set tape params */ MTIOCSETLIST/* set N params */ usr.bin/mt/Makefile: mt(1) now depends on libmt, libsbuf and libbsdxml. usr.bin/mt/mt.1: Document new mt(1) features and subcommands. usr.bin/mt/mt.c: Implement support for mt(1) subcommands that need to use getopt(3) for their arguments. Implement a new 'mt status' command to replace the old 'mt status' command. The old status command has been renamed 'ostatus'. The new status function uses the MTIOCEXTGET ioctl, and therefore parses the XML data to determine drive status. The -x argument to 'mt status' allows the user to dump out the raw XML reported by the kernel. The new status display is mostly the same as the old status display, except that it doesn't print the redundant density mode information, and it does print the current partition number and position flags. Add a new command, 'mt locate', that will supersede the old 'mt setspos' and 'mt sethpos' commands. 'mt locate' implements all of the functionality of the MTIOCEXTLOCATE ioctl, and allows the user to change the logical position of the tape drive in a number of ways. (Partition, block number, file number, set mark number, end of data.) The immediate bit and the explicit address bits are implemented, but not documented in the man page. Add a new 'mt weofi' command to use the new MTWEOFI ioctl. This allows the user to ask the drive to write a filemark without waiting around for the operation to complete. Add a new 'mt getdensity' command that gets the XML-based tape drive density report from the sa(4) driver and displays it. This uses the SCSI REPORT DENSITY SUPPORT command to get comprehensive information from the tape drive about what formats it is able to read and write. Add a new 'mt protect' command that allows getting and setting tape drive protection information. The protection information is a CRC tacked on to the end of every read/write from and to the tape drive. Sponsored by:Spectra Logic MFC after: 1 month Thanks, Ken -- Kenneth Merry k...@freebsd.org -- Kenneth Merry k...@freebsd.org ___ freebsd-s...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-scsi To unsubscribe, send any mail to freebsd-scsi-unsubscr...@freebsd.org — Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
On Feb 28, 2015, at 11:48 AM, Dan Langille d...@langille.org wrote: On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry k...@freebsd.org wrote: I have updated the patches. I have removed the XPT_DEV_ADVINFO changes from the patches to head, since I committed those separately. I have (hopefully) fixed the build for the stable/10 patches by MFCing dependencies. (One of them mav did for me, thanks!) Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt The patches against FreeBSD/head as of SVN revision 278975: http://people.freebsd.org/~ken/sa_changes.20150218.1.txt And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt Not sure what I've done wrong here. I've applied your patches and run make buildworld against: It appears 'patch -p0' is my friend... It's been a long time.. — Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. I have a DLT 8000 and an SDLT 220. I don't have anything running current, but I have a spare machine which I could use for testing. Do you see any value is tests with that hardware? I'd be testing it via Bacula. disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer. Actually, yes. Bacula is a bit tricky to configure, so your trying it out would be helpful if you have the time. I have been unable to test yet. I've encountered time and hardware issues. I may be able to try tomorrow. In looking at the manuals for both the SDLT 220 and the DLT 8000, they both claim to support long position information for the SCSI READ POSITION command. You can see what I'm talking about by doing: mt eod mt status On my DDS-4 tape drive, this shows: # mt -f /dev/nsa3 status Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY - Mode Density Blocksize bpi Compression Current: 0x26:DDS-4 1024 bytes 97000enabled (DCLZ) - Current Driver State: at rest. - Partition: 0 Calc File Number: -1 Calc Record Number: -1 Residual:0 Reported File Number: -1 Reported Record Number: -1 Flags: None But on an LTO-5, which will give long position information, I get: [root@doc ~]# mt status Drive: sa0: IBM ULTRIUM-HH5 E4J1 - Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 enabled (0x1) - Current Driver State: at rest. - Partition: 0 Calc File Number: 2 Calc Record Number: -1 Residual:0 Reported File Number: 2 Reported Record Number: 32373 Flags: None That, in combination with the changes I made to the position information code in the driver, mean that even the old MTIOCGET ioctl should return an accurate file number at end of data. e.g., on the LTO-5: [root@doc ~]# mt ostatus Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 0x1 -available modes- 0:0x58:LTO-5 variable 384607 0x1 1:0x58:LTO-5 variable 384607 0x1 2:0x58:LTO-5 variable 384607 0x1 3:0x58:LTO-5 variable 384607 0x1 - Current Driver State: at rest. - File Number: 2 Record Number: -1 Residual Count -1 So the thing to try, in addition to just making sure that Bacula continues to work properly, is to try setting this for the tape drive in bacula-sd.conf: Hardware End of Medium = yes It looks like the Bacula tape program (btape) has a test mode, and it would be good to run through the tests on one of the tape drives and see whether they work, and whether the results are different before and after the changes. I'm not sure how to enable the test mode. I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL. Thanks! If there are additional features they would like out of the tape driver, I'm happy to talk about it. (Or help if they'd like to use the new status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.) Ken -- Kenneth Merry k...@freebsd.org — Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. I have a DLT 8000 and an SDLT 220. I don't have anything running current, but I have a spare machine which I could use for testing. Do you see any value is tests with that hardware? I'd be testing it via Bacula. disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer. I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL. — Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Help saving my system
On 18 Oct 2003 at 12:16, Scott M. Likens wrote: [stuff deleted] Comments anyone? Yes. Next time, don't bother posting. -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help saving my system
On 18 Oct 2003 at 12:16, Scott M. Likens wrote: [stuff deleted] Comments anyone? Yes. Next time, don't bother posting. I apologise for my previous post. I should have added what I was thinking. That follows. There's little use or sense in reacting the way you did (not that my original post was much better). In reply to a plea for help, it would have been much better to have suggested course of action to remedy the situation, such as others have done. This is a community mailing list and people are expected to contribute in a positive manner. Ridicule is unacceptable. Cherse -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help saving my system
On 18 Oct 2003 at 16:24, Scott M. Likens wrote: --On Saturday, October 18, 2003 6:25 PM -0400 Dan Langille Cherse Cheers? ^^ Yeah, that's what it should have been. I blame my anticipation of the baseball game... -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
libc_r's wrapped version of write()
It's been just over three days since this was committed. No problem reports have arrived, but that may be because this fringe case hasn't been tested. A test is a tape backup which exceeds the tape size (i.e. spans two tapes). Can anyone try that test for me please? On 29 Sep 2003 at 6:41, Daniel Eischen wrote: deischen2003/09/29 06:41:26 PDT FreeBSD src repository Modified files: lib/libc_r/uthread uthread_write.c Log: If __sys_write() returns 0, allow that to exit the loop in libc_r's wrapped version of write() . Submitted by: [EMAIL PROTECTED] Revision ChangesPath 1.22 +2 -2 src/lib/libc_r/uthread/uthread_write.c -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KSE howto?
On 9 Sep 2003 at 17:06, Jesse Guardiani wrote: Howdy list, Is there a KSE howto guide anywhere? I'm thinking about updating my FreeBSD 5.1-RELEASE system to -CURRENT and compiling XFree, KDE, MySQL, and Apache2 with KSE support, just for fun. But I don't know how to enable KSE support at compile time... WOW! A -current question I can answer. I just enable libkse on 5.1-RELEASE. Do this: to use libkse under 5.*, 1 - add WITH_LIBMAP= yes to /etc/make.conf 2 - do a make clean in src/libexec/rtld-elf and make all install 3 - to /etc/libmap.conf, add: libc_r.so.5 libkse.so.1 libc_r.so libkse.so run. See also http://www.FreeBSD.org/cgi/man.cgi?query=libmap.confsektion=5apropos =0manpath=FreeBSD+5.1-RELEASE -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KSE howto?
On 9 Sep 2003 at 17:09, Daniel Eischen wrote: On Tue, 9 Sep 2003, Jesse Guardiani wrote: Howdy list, Is there a KSE howto guide anywhere? I'm thinking about updating my FreeBSD 5.1-RELEASE system to -CURRENT and compiling XFree, KDE, MySQL, and Apache2 with KSE support, just for fun. But I don't know how to enable KSE support at compile time... It will be easier to wait for ports@ to work out the issue with -pthread being removed. Then you should be able to set PTHREAD_LIBS=-lkse in /etc/make.conf and rebuild your ports. Until then, libmap.conf(5) is the easiest solution. Oh, well, perhaps my answer isn't correct after all... :( -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
databases/mysql323-client fails to build
On a 5.1-release box, I tried to install databases/mysql323-client and was told: configure: error: Your compiler cannot convert a longlong value to a float! If you are using gcc 2.8.# you should upgrade to egcs 1.0.3 or newer and try again. The output of databases/mysql323-client/work/mysql-3.23.57/config.log is at http://www.freebsddiary.org/tmp/config.log Any ideas? -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: databases/mysql323-client fails to build
On 29 Aug 2003 at 10:52, Paul Blazejowski wrote: On Fri, 2003-08-29 at 10:38, Dan Langille wrote: On a 5.1-release box, I tried to install databases/mysql323-client and was told: configure: error: Your compiler cannot convert a longlong value to a float! If you are using gcc 2.8.# you should upgrade to egcs 1.0.3 or newer and try again. The output of databases/mysql323-client/work/mysql-3.23.57/config.log is at http://www.freebsddiary.org/tmp/config.log Any ideas? I have submitted a bug report on Jul 27 to port maintainer [EMAIL PROTECTED] but never got a reply and the port is still broken on 5.1-RELEASE-p2.Perhaps it's time to move to version 4 of MySQL ... Do you have a PR #? Not much help here but i wanted to let you know you're not alone :-). We're now between a rock and a hard place. Bacula fails on -STABLE because of a pthreads bug. Tests run on 5.1 indicate the bug is not present there. But Bacula uses MySQL *grin* -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: databases/mysql323-client fails to build
On 29 Aug 2003 at 11:07, Tim Kientzle wrote:
On Fri, 2003-08-29 at 10:38, Dan Langille wrote:
On a 5.1-release box, I tried to install databases/mysql323-client
and was told:
configure: error: Your compiler cannot convert a longlong value to a
float!
If you are using gcc 2.8.# you should upgrade to egcs 1.0.3 or newer
and try again.
The output of databases/mysql323-client/work/mysql-3.23.57/config.log
is at http://www.freebsddiary.org/tmp/config.log
I just took a quick look, and the error message is probably
completely wrong. I don't think this has anything to do with
numeric conversions. Here's the relevant portion of config.log:
configure: program exited with status 139
configure: failed program was:
#line 16878 configure
#include confdefs.h
#include stdio.h
typedef long long longlong;
main()
{
longlong ll=1;
float f;
FILE *file=fopen(conftestval, w);
f = (float) ll;
fprintf(file,%g\n,f);
close(file);
exit (0);
}
If I understand correctly, status 139 is a signal 11 (SEGV)
with the core dump flag set. Sounds like you've tripped over
a library bug. It doesn't happen on my 5.1-RELEASE system, though.
Do you have the core dump file available? (I think it's in /tmp,
but could be wrong.) Could you send it to me? I suspect that
updating your libc might correct this, but would like to verify
that. I presume you built from source; do you happen to know the date?
If the file conftestval exists somewhere, send me that, too.
If you don't have a core file, copy and paste the above program
(you may also need to create confdefs.h, which is included at the
end of config.log), compile it with the following command, and try
running it. Let us know what happens on your system:
cc -o conftest -DDBUG_OFF -O -pipe -mcpu=pentiumproconftest.c -lz
-lcrypt -lm -pthread
$ ./conftest
Segmentation fault (core dumped)
--
Dan Langille : http://www.langille.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: databases/mysql323-client fails to build
On 29 Aug 2003 at 12:11, Tim Kientzle wrote: 1) cd /usr/ports/mysql323-client 1a) rm -rf work 2) make extract 3) vi work/mysql-3.23.57/configure search on 'longlong' to find the above program. Change close to fclose 4) make 5) make install There was a patch recently commited: http://www.freshports.org/databases/mysql323- server/[EMAIL PROTECTED] d.org Thanks. -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: databases/mysql323-client fails to build
On 29 Aug 2003 at 13:29, Joe Marcus Clarke wrote: This is due to a bug in the configure script - the patch was posted to this list several times over the last few months. Unfortunately the port maintainer is inactive - someone needs to commit the patch (and reset the maintainer to ports@) Done. What a guy! Thank you. The following PRs can be closed IMHO: client: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=54747 server: http://www.freebsd.org/cgi/query-pr.cgi?pr=53252 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=53561 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=53659 And these should be reviewed: client: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=55264 server: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24749 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=31943 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=47834 Mark Linimon supplied the list. I just looked them over. -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: databases/mysql323-client fails to build
On 29 Aug 2003 at 13:29, Joe Marcus Clarke wrote: This is due to a bug in the configure script - the patch was posted to this list several times over the last few months. Unfortunately the port maintainer is inactive - someone needs to commit the patch (and reset the maintainer to ports@) Done. Pssst! Should we change the databases/mysql323-server maintainer too? -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FW: Filesystem gets a huge performance boost
On 18 Apr 2001, at 22:16, Bruce Evans wrote: On Wed, 18 Apr 2001, Jeroen Ruigrok/Asmodai wrote: -On [20010417 20:47], Matt Dillon ([EMAIL PROTECTED]) wrote: Testing it 'on' in stable on production systems and observing the relative change in performance is a worthy experiment. Testing it 'on' in current is just an experiment. I have been running vfs.vmiodirenable=1 on two STABLE boxes for the last week or so. Still no problems. Been doing massive cvsups and all that. This is not in combination with softupdates. That's next on the agenda. So, how much slower was it? ;-) $ uname -a FreeBSD cvsup.nz.freebsd.org 4.2-STABLE FreeBSD 4.2-STABLE #0: Thu Mar 8 01:24:24 NZDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/ZEKE i386 The box I mentioned in my previous message is running softupdates. -- Dan Langille pgpkey - finger [EMAIL PROTECTED] | http://unixathome.org/finger.php To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A couple of Junior Hacker tasks...
On 28 Dec 2000, at 9:36, Poul-Henning Kamp wrote: which are good candidates for people looking for a good and simple task to do for FreeBSD. How do we know which are the "good and simple" ones? -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BUILDWORLD Problems
On 25 Feb 00, at 22:03, O. Hartmann wrote: One of our two servers will not perform "buildworld"! Well, kernel stuff should be on the newest track, I cvsup-dated them both today. After a short while making dependencies it stops with the following error: [snip] I deleted /usr/src/crypto and ./secure tree and made an other cvsupdate, but with no success. Compiled a new kernel, installed it ... no success. Why? The other machine has the same stuff, I cvsupdated the same way and today, but it performs the make world task without any problems. I can not understand this behaviour ... Please help. libcrypto is being updated. You (and the rest of us) will just have to wait until it's finished. See also the thead titled "Re: yes, current is broke...". -- Dan Langille - DVL Software Limited [I'm looking for more work] http://www.dvl-software.com/ | http://www.unixathome.org/ http://www.racingsystem.com/ | http://www.freebsddiary.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
yes, current is broke...
I'm guessing this is related to jkh's mention of OpenSSH coming into the tree, but I'm posting it anyway. Just in case it helps. my cvsup is less then 4 hours old. === libssl rm -f .depend mkdep -f .depend -a-DTERMIOS -DANSI_SOURCE -DNO_IDEA - I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto - I/usr/obj/usr/src/secure/lib/libssl -DL_ENDIAN - DDEVRANDOM=\"/dev/urandom\" -I/usr/obj/usr/src/i386/usr/include /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/bio_ssl.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_lib.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_meth.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_pkt.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_srvr.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s2_clnt.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s2_enc.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s2_lib.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s2_meth.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s2_pkt.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s2_srvr.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_both.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_enc.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_lib.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_meth.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_pkt.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_srvr.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_algs.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_asn1.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_cert.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_ciph.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_err.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_err2.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_lib.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_rsa.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_sess.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_stat.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_txt.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/t1_clnt.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/t1_enc.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/t1_lib.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/t1_meth.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/t1_srvr.c cd /usr/src/secure/lib/libssl; make _EXTRADEPEND echo libssl.so.1: /usr/obj/usr/src/secure/lib/libssl/openssl/opensslconf.h .depend === libssh make: don't know how to make strlcat.c. Stop *** Error code 2 Stop in /usr/src/secure/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Dan Langille - DVL Software Limited [I'm looking for more work] http://www.dvl-software.com/ | http://www.unixathome.org/ http://www.racingsystem.com/ | http://www.freebsddiary.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssl in -current
On 21 Feb 00, at 20:57, Dan Langille wrote: On 21 Feb 00, at 15:23, Daniel C. Sobral wrote: Christian Weisgerber wrote: binary installation: - before: user needs to install openssl port - now:user needs to install openssl package Where is the openssl package, and what it is called? security/openssl I must stop responding when I'm sleep deprived. -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssl in -current
On 21 Feb 00, at 15:23, Daniel C. Sobral wrote: Christian Weisgerber wrote: binary installation: - before: user needs to install openssl port - now:user needs to install openssl package Where is the openssl package, and what it is called? security/openssl -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: feedback on CD install of 4.0-RC2
On 20 Feb 00, at 6:56, Daniel C. Sobral wrote:
"Guided". I like it. That's *PRECISELY* what this installation option
is. There is NO difference in the number of choices available in any of
the three types.
I have many times encountered a user who avoided the NOVICE install
and tried one of the other methods. They clearly lacked the skill
necessary to perform anything *other* than a NOVICE install. I suspect
they avoided the NOVICE install because they didn't consider
themselves a novice ("But I've been using Linux for years!"). I think
calling it GUIDED will certainly reduce the number of calls for help.
--
Dan Langille - DVL Software Limited [I'm looking for more work]
The FreeBSD Diary - http://www.freebsddiary.org/
NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/
The Racing System - http://www.racingsystem.com/
unix @ home - http://www.unixathome.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: dc0 seems to affect other boxes
On 7 Feb 00, at 23:38, Dan Langille wrote: This 4.0-current box contains a 10/100 nic. This may sound strange, but I suspect this NIC is the cause of my problems, but I have no explanation as to why it. The above symptoms occur only when this box is running. The problems go away if I reboot the gateway (not a long term solution). To complicate the issue, said box is running FreeBSD 4.0-current. I have another box which is running 4.0-current, but it does not contain a 10/100 NIC. Upon rebooting the gateway, all is fine. But after about 10 minutes or so, the symptoms reappear. If I disconnect the 10/100 NIC from the hub, and reboot the gateway, all is well. My hub is a plain simple hub (works only with 10 not 100, I suspect). The 10/100 NIC has been configured thusly: A followup to the above. I replaced the 10/100 NIC with an old ed0. After a short time, the problem reappeared. At this point, I was advised to try another cable and a different port on the hub. After rebooting my gateway, every thing settle down and there have been no recurring problems. I have yet to isolate either the cable or the hub port as the cause of the problem, but at least I've eliminated the NIC and the OS. My thanks to those on undernet #freebsd which helped with this problem. -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slow to boot
On 7 Feb 00, at 18:12, Dan Langille wrote: I have one box which is slow to boot under -current (mind you, I've never run anything but -current on this box). There are two pauses. One after ata0 appears and another after ata-isa0 appears. I'm reposting this as there has been no response and the box still exhibits the original problems. Make world is about 12 hours old from a recent cvsup. Original message follows. Any ideas? cheers I have one box which is slow to boot under -current (mind you, I've never run anything but -current on this box). There are two pauses. One after ata0 appears and another after ata-isa0 appears. All times are approximate (I had to count, no watches to hand). This is written on the motherboard: P/I-P55TP4XE. tia folks. $ uname -a FreeBSD buff.unixathome.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sun Feb 6 18:05:58 NZDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/BUFF i386 [dan@buff:/usr/home/dan] $ dmesg Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun Feb 6 18:05:58 NZDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/BUFF Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (99.47-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping = 5 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 33554432 (32768K bytes) config di psm0 config di sn0 config di lnc0 config di le0 config di ie0 config di fe0 config di cs0 config di bt0 config di aic0 config di aha0 config di adv0 config q avail memory = 28835840 (28160K bytes) Preloaded elf kernel "kernel" at 0xc03b9000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03b909c. Intel Pentium detected, installing workaround for F00F bug md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: Intel 82371FB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX ATA controller port 0xe800-0xe80f at device 7.1 on pci0 ata0 at 0x01f0 irq 14 on ata-pci0 [insert approx 30s pause here] dc0: Macronix 98715/98715A 10/100BaseTX port 0xe400-0xe4ff mem 0xfbfa-0xfbfa00ff irq 11 at device 9.0 on pci0 dc0: Ethernet address: 00:80:ad:7f:4e:7b miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vga-pci0: ATI Mach64-CT graphics accelerator mem 0xfa00- 0xfaff at device 12.0 on pci0 fe0: not probed (disabled) fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ata-isa0: already registered as ata0 [insert approx 37s pause here] adv0: not probed (disabled) bt0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 pcic1: not probed (disabled) sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port plip0: PLIP network interface on ppbus0 ie0: not probed (disabled) le0: not probed (disabled) lnc0: not probed (disabled) cs0: not probed (disabled) sn0: not probed (disabled) IPsec: Initialized Security Association Processing. ad0: 1222MB QUANTUM FIREBALL1280A [2484/16/63] at ata0- master using WDMA2 Mounting root from ufs:/dev/ad0s1a -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slow to boot
On 14 Feb 00, at 11:15, Soren Schmidt wrote: It seems Dan Langille wrote: On 14 Feb 00, at 22:02, Dan Langille wrote: On 7 Feb 00, at 18:12, Dan Langille wrote: I have one box which is slow to boot under -current (mind you, I've never run anything but -current on this box). There are two pauses. One after ata0 appears and another after ata-isa0 appears. I'm reposting this as there has been no response and the box still exhibits the original problems. Make world is about 12 hours old from a recent cvsup. Original message follows. Any ideas? cheers The above message was prematurely ejected. Please ignore. Does that mean it works now ?? No, it means a message I was composing got out before I finished my testing and evaluation. I'm still trying a few more things, like removing devices from the kernel. I should know more within an hour or two (this box takes a while to compile a kernel). -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slow to boot
On 14 Feb 00, at 22:02, Dan Langille wrote: On 7 Feb 00, at 18:12, Dan Langille wrote: I have one box which is slow to boot under -current (mind you, I've never run anything but -current on this box). There are two pauses. One after ata0 appears and another after ata-isa0 appears. I'm reposting this as there has been no response and the box still exhibits the original problems. Make world is about 12 hours old from a recent cvsup. Original message follows. Any ideas? cheers The above message was prematurely ejected. Please ignore. -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slow to boot
On 7 Feb 00, at 18:12, Dan Langille wrote: I have one box which is slow to boot under -current (mind you, I've never run anything but -current on this box). There are two pauses. One after ata0 appears and another after ata-isa0 appears. I'm reposting this as there has been no response and the box still exhibits the original problems. Make world is about 12 hours old from a recent cvsup. Original message follows. Any ideas? cheers I have one box which is slow to boot under -current (mind you, I've never run anything but -current on this box). In my previous message, there were two excessively long pauses. One after ata0 appears and another after ata-isa0 appears. I've been able to eliminate one of these pauses. I removed this from my kernel: device ata1at isa? port IO_WD2 irq 15 All times are approximate (I had to count, no watches to hand). This is written on the motherboard: P/I-P55TP4XE. tia folks. Here's dmesg after a boot -v. [dan@buff:/usr/home/dan] $ dmesg Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Tue Feb 15 00:23:48 NZDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/BUFF Calibrating clock(s) ... TSC clock: 99464497 Hz, i8254 clock: 1193073 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium/P54C (99.47-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping = 5 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 33554432 (32768K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x003cb000 - 0x01ff7fff, 2958 bytes (7213 pages) config di psm0 config di sn0 config di lnc0 config di le0 config di ie0 config di fe0 config di cs0 config di bt0 config di aic0 config di aha0 config di adv0 config q avail memory = 28868608 (28192K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fb810 bios32: Entry = 0xfbcf0 (c00fbcf0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xbd20 pnpbios: Found PnP BIOS data at 0xc00fda40 pnpbios: Entry = f:580 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: ACPI: Preloaded elf kernel "kernel" at 0xc03b2000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03b20a8. Intel Pentium detected, installing workaround for F00F bug md0: Malloc disk Creating DISK md0 Math emulator present pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=122d8086) npx0: math processor on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 169348010 bytes/sec bzero() bandwidth = 633713561 bytes/sec pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=122d8086) pcib0: Host to PCI bridge on motherboard found- vendor=0x8086, dev=0x122d, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x122e, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x1230, revid=0x02 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base e800, size 4 found- vendor=0x1002, dev=0x4354, revid=0x41 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base fa00, size 24 pci0: PCI bus on pcib0 CPU Inactivity timer: clocks Peer Concurrency: enabled CPU-to-PCI Write Bursting: enabled PCI Streaming: enabled Bus Concurrency: enabled Cache: NO asynchronous secondary; L1 enabled DRAM: no memory hole, 66 MHz refresh Read burst timing: x-2-2-2/x-3-3-3 Write burst timing: x-3-3-3 RAS-CAS delay: 3 clocks isab0: Intel 82371FB PCI to ISA bridge at device 7.0 on pci0 I/O Recovery Timing: 8-bit 1 clocks, 16-bit 1 clocks Extended BIOS: disabled Lower BIOS: enabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: disabled, B: disabled, C: disabled, D: disabled MB0: IRQ15, MB1: disabled isa0: ISA bus on isab0 ata-pci0: Intel PIIX ATA controller port 0xe800-0xe80f at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xe800 ata0: mask=03 status0=50 status1=00 ata0: mask=03 status0=50 status1=00 ata0: devices = 0x1 ata0 at 0x01f0 irq 14 on ata-pci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xe808 ata1: mask=03 status0=80 status1=80 [insert 37s pause here]
dc0 seems to affect other boxes
robed (disabled) sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port plip0: PLIP network interface on ppbus0 ie0: not probed (disabled) le0: not probed (disabled) lnc0: not probed (disabled) cs0: not probed (disabled) sn0: not probed (disabled) IPsec: Initialized Security Association Processing. ad0: 1222MB QUANTUM FIREBALL1280A [2484/16/63] at ata0- master using WDMA2 Mounting root from ufs:/dev/ad0s1a -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
slow to boot
I have one box which is slow to boot under -current (mind you, I've never run anything but -current on this box). There are two pauses. One after ata0 appears and another after ata-isa0 appears. All times are approximate (I had to count, no watches to hand). This is written on the motherboard: P/I-P55TP4XE. tia folks. $ uname -a FreeBSD buff.unixathome.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sun Feb 6 18:05:58 NZDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/BUFF i386 [dan@buff:/usr/home/dan] $ dmesg Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun Feb 6 18:05:58 NZDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/BUFF Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (99.47-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping = 5 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 33554432 (32768K bytes) config di psm0 config di sn0 config di lnc0 config di le0 config di ie0 config di fe0 config di cs0 config di bt0 config di aic0 config di aha0 config di adv0 config q avail memory = 28835840 (28160K bytes) Preloaded elf kernel "kernel" at 0xc03b9000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03b909c. Intel Pentium detected, installing workaround for F00F bug md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: Intel 82371FB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX ATA controller port 0xe800-0xe80f at device 7.1 on pci0 ata0 at 0x01f0 irq 14 on ata-pci0 [insert approx 30s pause here] dc0: Macronix 98715/98715A 10/100BaseTX port 0xe400-0xe4ff mem 0xfbfa-0xfbfa00ff irq 11 at device 9.0 on pci0 dc0: Ethernet address: 00:80:ad:7f:4e:7b miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vga-pci0: ATI Mach64-CT graphics accelerator mem 0xfa00-0xfaff at device 12.0 on pci0 fe0: not probed (disabled) fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ata-isa0: already registered as ata0 [insert approx 37s pause here] adv0: not probed (disabled) bt0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 pcic1: not probed (disabled) sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port plip0: PLIP network interface on ppbus0 ie0: not probed (disabled) le0: not probed (disabled) lnc0: not probed (disabled) cs0: not probed (disabled) sn0: not probed (disabled) IPsec: Initialized Security Association Processing. ad0: 1222MB QUANTUM FIREBALL1280A [2484/16/63] at ata0-master using WDMA2 Mounting root from ufs:/dev/ad0s1a -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems make installworld
On 5 Feb 00, at 1:06, Warner Losh wrote: In message [EMAIL PROTECTED] "Dan Langille" writes: : OK. I'll cvsup to be sure I have the latest. And try the whole process : again. FWIW: I'm following the instructions mentioned by Jim Bloom in : the UPDATING thread (msg id = [EMAIL PROTECTED]). : : cheers : : cd /usr/src : make buildworld : make installworld : cd /usr/src/usr.bin/xinstall : make install : cd /usr/src : make installworld Let me know if this works, and I'll commit something to UPDATING. However, I think this is moot based on other commits that have happened. Sure thing. This might take up to 24 hours. It's a P100 with only 16MB ram and I'm away most of tomorrow. p.s. thanks for maintaining UPDATING. It's saved me more than one search through the archives. Cheers. -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems make installworld
On 5 Feb 00, at 16:35, Ruslan Ermilov wrote: On Sat, Feb 05, 2000 at 08:47:19PM +1300, Dan Langille wrote: On 5 Feb 00, at 9:28, Ruslan Ermilov wrote: On Sat, Feb 05, 2000 at 07:41:56PM +1300, Dan Langille wrote: I'm experiencing the same problems but the proposed solution of "make -k -DNOFSCHG installworld " doesn't allow the following "make installworld" to succeed. The error messages remain unchanged. I cvsup'd about 24 hours ago. Hmm, I have received successful reports from some people. You are doing something different. We are talking about DESTDIR=/ case, and the latest bsd.lib.mk with unbroken PRECIOUSLIB feature. -DNOFSCHG is required to install without -fschg new shared libraries, in particular, libc.so.4 with setflags. -k is required since there is no such a beast like NOFSCHG for bsd.prog.mk. So, on the first pass you should have *all* new libraries installed, and some programs like /bin/rcp (which are installed with flags) not installed. On the second pass everything will be installed, since we at this point we already have the new /usr/bin/install and new libc.so.4. OK. I'll cvsup to be sure I have the latest. And try the whole process again. FWIW: I'm following the instructions mentioned by Jim Bloom in the UPDATING thread (msg id = [EMAIL PROTECTED]). cheers cd /usr/src make buildworld make installworld cd /usr/src/usr.bin/xinstall make install cd /usr/src make installworld This will not work, since with new bsd.lib.mk libc.so.4 will not be installed on the first installworld path. Just add -DNOFSCHG to the first `make installworld' (line 3 above), and the procedure will work. I.e., first installworld (with -DNOFSCHG) will fail on bin/rcp, but at this point you'll already have the correct libc.so.4. Then you will install the new /usr/bin/install, and repeat installworld. The following did me fine for a make world: make installworld make -k -DNOFSCHG installworld Last cvsup was done 13 hours ago. -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
visual config hangs
I tried to swap network cards today. So I did a boot -c then went into visual config. After adding ed0 back in and modifying, then saving the values for it, I did a Q to quit and a Y to save. That was about 20 minutes ago. It's still sitting on the visual screen. Is this a known isssue? My last cvsup was about 18 hours ago. On a side note, is there any documentation on kernel.conf? I want to enable ed0, change the base address and IOMEM. Does anyone have an example? -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: visual config hangs
On 6 Feb 00, at 14:13, Dan Langille wrote: I tried to swap network cards today. So I did a boot -c then went into visual config. After adding ed0 back in and modifying, then saving the values for it, I did a Q to quit and a Y to save. That was about 20 minutes ago. It's still sitting on the visual screen. I think we can safely ignore the above. I think it was because I removed PC-CARD from the configuration. More importantly, changes made during the above visual config are not being saved. This sounds like the problem 3.1-RELEASE had. /boot/kernel.conf remains unchanged after adding in ed0 and configuring it. -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UPDATING - kernel fails to compile
I can't get my kernel to compile when following the UPDATING instructions. I also note that the "To build a kernel" instructions contains one too many "../". Here's what led me to it: [root@buff:/usr/src/sys/compile/BUFF] # make install install -c -m 555 -o root -g wheel -fschg kernel /kernel /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" *** Error code 1 Stop in /usr/src/sys/compile/BUFF. [insert lightbulb here] Ahhh, yes, /usr/src/UPDATING has the right stuff. cd src/usr.bin/genassym make depend all install clean cd ../../usr.sbin/config make depend all install clean cd ../../../sys/i386/conf=== wrong *** config YOUR_KERNEL_HERE cd ../../compile/YOUR_KERNEL_HERE make depend make *** should be cd ../../sys/i386/conf but following the above instructions still gives me: [root@buff:/usr/src/sys/compile/BUFF] # make install install -c -m 555 -o root -g wheel -fschg kernel /kernel /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" *** Error code 1 Stop in /usr/src/sys/compile/BUFF. # uname -a FreeBSD buff.unixathome.org 4.0-2127-CURRENT FreeBSD 4.0- 2127-CURRENT #0: Thu Jan 27 15:14:24 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386 cvsup is about 15 hours old and make world was just done. cheers. -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING - kernel fails to compile
I think you mean -DNOFSCHG, which it what I thought I did. I shall try again. cheers. On 5 Feb 00, at 21:25, Jim Bloom wrote: You still didn't get your installworld to complete succesfully. You have install, libc, and libutil out of sync. I believe the correct procedure for installing everything in your case is: make -k -NOFSCHG installworld make installworld Jim Bloom [EMAIL PROTECTED] Dan Langille wrote: [root@buff:/usr/src/sys/compile/BUFF] # make install install -c -m 555 -o root -g wheel -fschg kernel /kernel /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" *** Error code 1 -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING - kernel fails to compile
After a make -k -DNOFSCHG installworld and a make installworld, I'm getting this: install -c -s -o root -g wheel -m 555 genassym /usr/bin install: genassym: No such file or directory *** Error code 71 Stop in /usr/src/usr.bin/genassym. *** Error code 1 Stop in /usr/src/usr.bin. *** Errror code 1 etc... Failing other suggestions, I'm about to do a make clean make buildworld make -k -DNOFSCHG installworld make installworld perhaps something else is fuggered. Thanks. On 5 Feb 00, at 21:25, Jim Bloom wrote: You still didn't get your installworld to complete succesfully. You have install, libc, and libutil out of sync. I believe the correct procedure for installing everything in your case is: make -k -NOFSCHG installworld make installworld Jim Bloom [EMAIL PROTECTED] Dan Langille wrote: [root@buff:/usr/src/sys/compile/BUFF] # make install install -c -m 555 -o root -g wheel -fschg kernel /kernel /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" *** Error code 1 -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING - kernel fails to compile
On 5 Feb 00, at 22:30, Chuck Robey wrote: On Sun, 6 Feb 2000, Dan Langille wrote: After a make -k -DNOFSCHG installworld and a make installworld, I'm getting this: install -c -s -o root -g wheel -m 555 genassym /usr/bin install: genassym: No such file or directory *** Error code 71 It's a do-once type of thing, like the xinstall stuff. Go install genassym once, it won't bother you again. It was discussed in the lists, and doesn't affect most build intervals. You got *lucky*. Ahh yes, and it's in UPDATING. my bad. Sorry. I tried that. Then did a make installworld. Then I found that conifig wasn't installed either. so I did a cd usr.sbin/config make make install cd /usr/src make installworld then I followed these instructions from UPDATING for making a kernel: cd src/usr.bin/genassym make depend all install clean cd ../../usr.sbin/config make depend all install clean cd ../../../sys/i386/conf config YOUR_KERNEL_HERE cd ../../compile/YOUR_KERNEL_HERE make depend make Some of that may have been redundant, given my make installworld problems, but so be it. I got *lucky*? What? twice in one weekend? /me beams. Thanks to those that have helped. Everything built this time. cheers. -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems make installworld
I'm experiencing the same problems but the proposed solution of "make -k -DNOFSCHG installworld " doesn't allow the following "make installworld" to succeed. The error messages remain unchanged. I cvsup'd about 24 hours ago. cheers On 4 Feb 00, at 17:44, Ruslan Ermilov wrote: On Fri, Feb 04, 2000 at 03:17:49PM +0100, Kurt Bauer wrote: Whenever I try to do a 'make installworld' the following error occurs: /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" That is the case I was talking about when I fixed bsd.lib.mk's PRECIOUSLIB breakage. Unfortunately, you are one of those guys, who had their /usr/bin/install linked with libutil, cvsupped the latest -current (with fixed bsd.lib.mk), and ran make installworld. The solution for you is: 1. make -k -DNOFSCHG installworld (this will allow you to install new libc.so.4). Both -k and -DNOFSCHG are required. 2. make a normal installworld. Please let me know whether it works for you. A quicker solution would be to copy (by hands) new libc.so.4 from /usr/obj to /usr/lib, and go to the step 2 above. But I really like you test step1, step2 algorithm, because we might want to upgrade UPDATING instructions. When I do a 'make -k installworld', make continues but the error occurs several times. When I do a simple 'make installworld' the followin happens : install -c -s -o root -g wheel -m 444 -fschg libscrypt.so.2 /usr/lib /usr/libexec/ld-elf.so.1: install: Undefined symbol "setflags" *** Error code 1 Stop in /usr/src/lib/libcrypt. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 I really hope someone can help me, cause I want to test the IPv6 things in 4.0 soon (for my thesis) Thanx, Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Ruslan ErmilovSysadmin and DBA of the [EMAIL PROTECTED] United Commercial Bank, [EMAIL PROTECTED]FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems make installworld
On 5 Feb 00, at 9:28, Ruslan Ermilov wrote: On Sat, Feb 05, 2000 at 07:41:56PM +1300, Dan Langille wrote: I'm experiencing the same problems but the proposed solution of "make -k -DNOFSCHG installworld " doesn't allow the following "make installworld" to succeed. The error messages remain unchanged. I cvsup'd about 24 hours ago. Hmm, I have received successful reports from some people. You are doing something different. We are talking about DESTDIR=/ case, and the latest bsd.lib.mk with unbroken PRECIOUSLIB feature. -DNOFSCHG is required to install without -fschg new shared libraries, in particular, libc.so.4 with setflags. -k is required since there is no such a beast like NOFSCHG for bsd.prog.mk. So, on the first pass you should have *all* new libraries installed, and some programs like /bin/rcp (which are installed with flags) not installed. On the second pass everything will be installed, since we at this point we already have the new /usr/bin/install and new libc.so.4. OK. I'll cvsup to be sure I have the latest. And try the whole process again. FWIW: I'm following the instructions mentioned by Jim Bloom in the UPDATING thread (msg id = [EMAIL PROTECTED]). cheers cd /usr/src make buildworld make installworld cd /usr/src/usr.bin/xinstall make install cd /usr/src make installworld -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
anyone got IP Filter 3.3.8 working?
Make world has been done within the past 6 hours. When compiling a new kernel for IP Filter 3.3.8, I encounter the following warnings during the make depend: In file included from ../../netinet/fil.c:27: ../../sys/ioctl.h:46: warning: #warning "Don't #include ioctl.h in the kernel. Include xxxio.h instead." In file included from ../../netinet/ip_nat.c:37: ../../sys/ioctl.h:46: warning: #warning "Don't #include ioctl.h in the kernel. Include xxxio.h instead." In file included from ../../netinet/ip_frag.c:31: ../../sys/ioctl.h:46: warning: #warning "Don't #include ioctl.h in the kernel. Include xxxio.h instead." In file included from ../../netinet/ip_state.c:38: ../../sys/ioctl.h:46: warning: #warning "Don't #include ioctl.h in the kernel. Include xxxio.h instead." In file included from ../../netinet/ip_auth.c:26: And the following error during the make: cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat- extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL - include opt_global.h -elf -mpreferred-stack-boundary=2 ../../netinet/mlfk_ipl.c ../../netinet/mlfk_ipl.c:77: `ipl_inited' undeclared here (not in a function) ../../netinet/mlfk_ipl.c:77: initializer element is not constant ../../netinet/mlfk_ipl.c:77: (near initialization for `sysctl___net_inet_ipf_ipl_inited.oid_arg1') *** Error code 1 Anyone else encountered this? -- Dan Langille - DVL Software Limited [I'm looking for more work] The FreeBSD Diary - http://www.freebsddiary.org/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/ unix @ home - http://www.unixathome.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tcp_wrapper in contrib and ports?
On 7 Jun 99, at 16:34, Dom Mitchell wrote: On 7 June 1999, Ben Rosengart proclaimed: I am curious as to why tcp_wrappers are present in /usr/src/contrib as well as in the ports collection. Can someone please enlighten me? TIA. To support 2.2.x users? Yes. Please don't forget about us! [using 2.2.8 and 3.1] -- Dan Langille - DVL Software Limited The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/racingsystem.htm To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Announcing a new cvsup server - cvsup6.freebsd.org
On 30 May 99, at 18:03, Kris Kennaway wrote: I'm sure there are many people who aren't using the optimal server for their network location. FWIW: I had someone in the Netherlands using cvsup.nz.freebsd.org for a bit. They claimed better times than stuff like Dallas or someething. cvsup, when it was up, was an old 486. It's down now, but it should return within the next few weeks. slight niggle to be ignored Umm, well, actually, we're waiting for ncr to work under 3.* and then we'll upgrade and deploy the box. /slight niggle to be ignored -- Dan Langille - DVL Software Limited The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/racingsystem.htm To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FTP passive mode - a new default?
On 26 May 99, at 23:50, Adam wrote: Unless I hear unanimous fierce outcry against it, I'm strongly considering making FTP_PASSIVE_MODE obsolete by virtue of being the default for all tools/libraries which currently examine it. If they already examine FTP_PASSIVE_MODE, why not just set it to YES by default somewhere? That makes more sense to me than introducing a new flag. -- Dan Langille - DVL Software Limited The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/racingsystem.htm To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FTP passive mode - a new default?
On 26 May 99, at 3:50, Jordan K. Hubbard wrote: Unless I hear unanimous fierce outcry against it, I'm strongly considering making FTP_PASSIVE_MODE obsolete by virtue of being the default for all tools/libraries which currently examine it. FTP_ACTIVE_MODE will be the new flag for toggling the previous behavior. Given the state of the Internet today, I think this is purely a sensible change in defaults. Comments? It would surely simplify some things. If you are using a firewall, you'll need passive mode. If you're not using a firewall, passive mode won't bother you one bit. For the argument that some ftp servers don't accept passive mode, I say it's a question of numbers: which default setting will satisfy the greatest number of people? which setting will reduce the number of questions how do I do X? -- Dan Langille - DVL Software Limited The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/racingsystem.htm To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ncr scsi doesn't boot
Here's what it is under 2.2.8: Probing for devices on PCI bus 0: chip0 Intel 82424ZX (Saturn) cache DRAM controller rev 2 on pci0:0:0 ncr0 ncr 53c810 fast10 scsi rev 1 int a irq 11 on pci0:1:0 The following snapshots fail to find it: 3.1-19990421-STABLE no disks found, no PCI probes done 4.0-19990418-CURRENT gets to visual configuration but no PCI probing. 4.0-19990420-CURRENT gets to visual configuration but no PCI probing. 4.0-19990421-CURRENT after visual configuration, it stops at rootfs is 2880 bytes compiled in MFS. No PCI probes at all. Doesn't get to visual configuration At that point, I gave up. cheers. btw: this is the new NZ mirror I'm trying to set up. Mind you, we can always run it on 2.2.8. But I'd prefer 3.1. -- Dan Langille - DVL Software Limited The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/racingsystem.htm To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
