Feature request (pam/nss ldap, nsswitch ldap integration)
Hi First of all, I know that most committers or contributors contribute their work in their free time. I am not asking for any promise but I just want to discuss a possible improvement for FreeBSD. So my suggestion is: integrate pam_ldap, nss_ldap, nsswitch support with ldap and lookupd (ie LDAP client support) into the OS. Perhaps by default, the ldap support is off. It can be enabled by a switch in /etc/make.conf (like KERBEROS) FreeBSD has the above support in the ports. But I think it would be great if FreeBSD support LDAP out of the box. Just like Solaris and most Linux distro. The integration with LDAP is like the integration of OpenPAM, OpenSSH, AMD automounter and BIND in FreeBSD. Please express your view. Ignore me if my suggestion has no practical use or only beneficial to a small amount of people. Regards Patrick _ 必殺技、飲歌、小星星... 浪漫鈴聲 情心連繫 http://us.rd.yahoo.com/evt=22281/*http://ringtone.yahoo.com.hk/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: questionable feature in FreeBSD pmake
> > Why are you unable to do anything with the command-line? Any of these > will solve your problem. > Bourne: > MAKEOBJDIR=/no_obj_here make > > Bourne or CSH: > env MAKEOBJDIR=/no_obj_here make > > Here is a Makefile that does not use obj/. The special targets can be > placed into a file to be included into all your Makefiles. It only > suffers from a failed build where it will not rename obj to tmpobj. > > --- > .BEGIN: > mv tmpobj obj || mkdir obj > > .INTERRUPT: > mv obj tmpobj > My goal was to write a generic makefile that would work on almost any mostly POSIX compliant OS. I wanted something I could just walk up to and say "make" without having to remember that the makefile is special and has to be invoked in a special way. If I could just add some trivial magic to the makefile that suppresses the special "obj" feature on systems that have it but has no effect on other systems, I would do that. It seems that there is no such magic. Thank you all for your suggestions. I wish to give a special award for extra creativity to Sean Farley for his makefile enhancements that work around the problem by temporarily renaming the "obj" subdirectory while the makefile is not active (i.e. when you would most care what the subdirectory was called). I think I will work around the problem by calling the directory "objs" instead of "obj". This does not mean that I forgive whoever it was that invented the feature I don't like. He should have checked with an adult first. (Ooh, it feels good to say that! :-) I repeat the observation that this feature could have been implemented in a way that would have made it unlikely to be invoked accidentally. It seems that the feature is now so widely spread throughout the BSD community that is way too late to get the blemish fixed now. I will have to settle for finding some comfort in the realization that I have far bigger problems than the inability to use the directory name "obj" in some circumstances. Dan Strick [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
Add Western Digital Raptors to the list as well. However I have not had a problem since 5.3-BETA3. aaron.glenn On Fri, 29 Oct 2004 16:57:33 +, Mikhail P. <[EMAIL PROTECTED]> wrote: > On Friday 29 October 2004 16:50, Mikhail P. wrote: > > Perhaps it is only Seagate <-> FreeBSD5-related. Same drives, but with > > FreeBSD4 do work well together without a glitch. > > Actually not only seagates.. similar happened on a 200GB Western Digital drive > to me, FreeBSD-5.3. > > > > regards, > M. > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
On Fri, 29 Oct 2004, Mikhail P. wrote: > On Friday 29 October 2004 16:50, Mikhail P. wrote: > > Perhaps it is only Seagate <-> FreeBSD5-related. Same drives, but with > > FreeBSD4 do work well together without a glitch. > > Actually not only seagates.. similar happened on a 200GB Western Digital drive > to me, FreeBSD-5.3. > In FreeBSD 5.3b7 I have the same problem with the Maxtor 120GB IDE ad2: 117246MB [238216/16/63] at ata1-master UDMA66 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=14301663 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=160532482 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=209834594 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=218490706 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=211340046 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=209834594 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=163587418 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=209834786 ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=17312287 - With best regards, |The Power to Serve Nguyen Tam Chinh| http://www.FreeBSD.org Loc: sp.cs.msu.ru | http://chinhngt.svmgu.com | http://www.gnu.org/copyleft/copyleft.html Tel: +7 905 7814187 | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: flushing disk buffer cache
On 29 Oct, Siddharth Aggarwal wrote:
>
> Thanks for your reply.
>
> Hmm. At the moment, the user can send an ioctl to define a checkpoint. But
> I would guess that this could happen between 2 strategy() function calls
> corresponding to the same filesystem operation?
Yes.
> So if there a way to block
> filesystem operations while a snapshot is taken? I can't unmount an active
> filesystem before the snapshot and remount it after. Any suggestions?
Yes, this is done by the following code in ffs_snapshot():
/*
* Suspend operation on filesystem.
*/
for (;;) {
vn_finished_write(wrtmp);
if ((error = vfs_write_suspend(vp->v_mount)) != 0) {
vn_start_write(NULL, &wrtmp, V_WAIT);
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
goto out;
}
if (mp->mnt_kern_flag & MNTK_SUSPENDED)
break;
vn_start_write(NULL, &wrtmp, V_WAIT);
}
I think the snapshot code works at a higher level than what you are
implementing, so I believe that the snapshot code doesn't need to sync
all the files to create a consistent snapshot. You may run into
problems with syncing unwritten data while writing is suspended, but I'm
not sure because don't understand the code all that well.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: flushing disk buffer cache
Thanks for your reply. Hmm. At the moment, the user can send an ioctl to define a checkpoint. But I would guess that this could happen between 2 strategy() function calls corresponding to the same filesystem operation? So if there a way to block filesystem operations while a snapshot is taken? I can't unmount an active filesystem before the snapshot and remount it after. Any suggestions? On Fri, 29 Oct 2004, Don Lewis wrote: > On 29 Oct, Siddharth Aggarwal wrote: > > > > Another related question ... > > > > Is it possible to delay or queue up disk writes until I exit from my > > function in the kernel (where I am trying to sync with the disk)? Or > > make sure that my sync function never goes to sleep waiting for the disk > > driver to signal completion of flushes to disk? > > Take a look at how the snapshot code handles this. It has to be done > above the level of individual disk operations because certain file > system operations require multiple disk I/O operations to transform the > file system from one consistent state to another consistent state. If > you try to checkpoint in the middle of this sequence, you will capture a > state where the file system is internally inconsistent. > > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: flushing disk buffer cache
On 29 Oct, Siddharth Aggarwal wrote: > > Another related question ... > > Is it possible to delay or queue up disk writes until I exit from my > function in the kernel (where I am trying to sync with the disk)? Or > make sure that my sync function never goes to sleep waiting for the disk > driver to signal completion of flushes to disk? Take a look at how the snapshot code handles this. It has to be done above the level of individual disk operations because certain file system operations require multiple disk I/O operations to transform the file system from one consistent state to another consistent state. If you try to checkpoint in the middle of this sequence, you will capture a state where the file system is internally inconsistent. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: flushing disk buffer cache
Another related question ...
Is it possible to delay or queue up disk writes until I exit from my
function in the kernel (where I am trying to sync with the disk)? Or
make sure that my sync function never goes to sleep waiting for the disk
driver to signal completion of flushes to disk?
On Fri, 29 Oct 2004, Siddharth Aggarwal wrote:
>
>
> Hi,
>
> I am writing this pseudo disk driver for disk checkpointing, which
> intercepts write requests to the disk (ad0s1) and performs a copy on write
> of the old contents to another partition (ad0s4) before writing out the
> new contents. So the driver (called shd) is mounted as
>
> /dev/shd0a on /
> /dev/shd0f on /usr
>
>
> So each time the user creates a new checkpoint (basically initialize new
> data structures in memory for a new checkpoint), right before that inside
> the driver, I explicitly do a sync() to flush out the disk buffer cache,
> so that disk state is consistent when the checkpoint was taken.
>
> Then, I have hacked the reboot system call to revert to a previous
> checkpoint after unmounting all the filesystems but before halting the
> system. This revert basically involves copying some blocks from ad0s4 to
> ad0s1.
>
> However, when the system reboots, fsck shows up inconsistencies in the
> filesystem and so fsck needs to be run manually.
>
> So I suspect that the reason for this problem is that when a checkpoint is
> taken, the filesystem on ad0s1 is active and more write operations are
> coming in i.e. filesystem on ad0s1 is still dirty. Hence I explicitly
> called sync() before returning from the checkpoint command but I think
> sync() doesnt guarantee that everything was actually flushed out. So I
> implemented a more mandatory way of syncing, i.e. just got part of the
> code from boot() system call. The code is as below, and it is called
> whenever a checkpoint command is fired.
>
> Does anyone think if this is the right way of flushing the cache? Is there
> anything I can do to ensure the filesystem is consistent during reboot?
> I don't think this is a problem in the driver code, because when I created
> a new filesystem on ad0s3 and shadowed that using the driver, everything
> ran perfectly fine, but the difference was that I could unmount the
> filesystem before "restoring the checkpoint" and hence wasnt necessary to
> do it during reboot time.
>
>
> void sync_before_checkpoint (void)
> {
> register struct buf *bp;
> int iter, nbusy, pbusy;
>
> waittime = 0;
> sync(&proc0, NULL);
>
> /*
> * With soft updates, some buffers that are
> * written will be remarked as dirty until other
> * buffers are written.
> */
>
> for (iter = pbusy = 0; iter < 20; iter++) {
> nbusy = 0;
> for (bp = &buf[nbuf]; --bp >= buf; ) {
> if ((bp->b_flags & B_INVAL) == 0 &&
> BUF_REFCNT(bp) > 0) {
> nbusy++;
> } else if ((bp->b_flags & (B_DELWRI | B_INVAL))
> == B_DELWRI) {
> /* bawrite(bp);*/
> nbusy++;
> }
> }
> if (nbusy == 0)
> break;
> printf("%d ", nbusy);
> if (nbusy < pbusy)
> iter = 0;
> pbusy = nbusy;
> if (iter > 5 && bioops.io_sync)
> (*bioops.io_sync)(NULL);
> sync(&proc0, NULL);
> DELAY(5 * iter);
> }
> /*
> * Count only busy local buffers to prevent forcing
> * a fsck if we're just a client of a wedged NFS server
> */
> nbusy = 0;
> for (bp = &buf[nbuf]; --bp >= buf; ) {
> if (((bp->b_flags&B_INVAL) == 0 && BUF_REFCNT(bp)) ||
> ((bp->b_flags & (B_DELWRI|B_INVAL)) == B_DELWRI)) {
> if (bp->b_dev == NODEV) {
> TAILQ_REMOVE(&mountlist,
> bp->b_vp->v_mount, mnt_list);
> continue;
> }
> nbusy++;
> }
> }
> if (nbusy) {
> /*
> * Failed to sync all blocks. Indicate this and don't
> * unmount filesystems (thus forcing an fsck on reboot).
> */
> printf("giving up on %d buffers\n", nbusy);
> DELAY(500); /* 5 seconds */
> }
> }
>
>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
On Friday 29 October 2004 16:50, Mikhail P. wrote: > Perhaps it is only Seagate <-> FreeBSD5-related. Same drives, but with > FreeBSD4 do work well together without a glitch. Actually not only seagates.. similar happened on a 200GB Western Digital drive to me, FreeBSD-5.3. regards, M. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
On Friday 29 October 2004 16:44, [EMAIL PROTECTED] wrote: > The same problem with similar IDE Seagate HDD: > > ad0: ATA-6 disk at ata0-master > ad0: 152627MB (312581808 sectors), 310101 C, 16 H, 63 S, 512 B > [...] > ad0: FAILURE - READ_DMA status=51 error=10 > LBA=268435455 Perhaps it is only Seagate <-> FreeBSD5-related. Same drives, but with FreeBSD4 do work well together without a glitch. regards, M. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
flushing disk buffer cache
Hi,
I am writing this pseudo disk driver for disk checkpointing, which
intercepts write requests to the disk (ad0s1) and performs a copy on write
of the old contents to another partition (ad0s4) before writing out the
new contents. So the driver (called shd) is mounted as
/dev/shd0a on /
/dev/shd0f on /usr
So each time the user creates a new checkpoint (basically initialize new
data structures in memory for a new checkpoint), right before that inside
the driver, I explicitly do a sync() to flush out the disk buffer cache,
so that disk state is consistent when the checkpoint was taken.
Then, I have hacked the reboot system call to revert to a previous
checkpoint after unmounting all the filesystems but before halting the
system. This revert basically involves copying some blocks from ad0s4 to
ad0s1.
However, when the system reboots, fsck shows up inconsistencies in the
filesystem and so fsck needs to be run manually.
So I suspect that the reason for this problem is that when a checkpoint is
taken, the filesystem on ad0s1 is active and more write operations are
coming in i.e. filesystem on ad0s1 is still dirty. Hence I explicitly
called sync() before returning from the checkpoint command but I think
sync() doesnt guarantee that everything was actually flushed out. So I
implemented a more mandatory way of syncing, i.e. just got part of the
code from boot() system call. The code is as below, and it is called
whenever a checkpoint command is fired.
Does anyone think if this is the right way of flushing the cache? Is there
anything I can do to ensure the filesystem is consistent during reboot?
I don't think this is a problem in the driver code, because when I created
a new filesystem on ad0s3 and shadowed that using the driver, everything
ran perfectly fine, but the difference was that I could unmount the
filesystem before "restoring the checkpoint" and hence wasnt necessary to
do it during reboot time.
void sync_before_checkpoint (void)
{
register struct buf *bp;
int iter, nbusy, pbusy;
waittime = 0;
sync(&proc0, NULL);
/*
* With soft updates, some buffers that are
* written will be remarked as dirty until other
* buffers are written.
*/
for (iter = pbusy = 0; iter < 20; iter++) {
nbusy = 0;
for (bp = &buf[nbuf]; --bp >= buf; ) {
if ((bp->b_flags & B_INVAL) == 0 &&
BUF_REFCNT(bp) > 0) {
nbusy++;
} else if ((bp->b_flags & (B_DELWRI | B_INVAL))
== B_DELWRI) {
/* bawrite(bp);*/
nbusy++;
}
}
if (nbusy == 0)
break;
printf("%d ", nbusy);
if (nbusy < pbusy)
iter = 0;
pbusy = nbusy;
if (iter > 5 && bioops.io_sync)
(*bioops.io_sync)(NULL);
sync(&proc0, NULL);
DELAY(5 * iter);
}
/*
* Count only busy local buffers to prevent forcing
* a fsck if we're just a client of a wedged NFS server
*/
nbusy = 0;
for (bp = &buf[nbuf]; --bp >= buf; ) {
if (((bp->b_flags&B_INVAL) == 0 && BUF_REFCNT(bp)) ||
((bp->b_flags & (B_DELWRI|B_INVAL)) == B_DELWRI)) {
if (bp->b_dev == NODEV) {
TAILQ_REMOVE(&mountlist,
bp->b_vp->v_mount, mnt_list);
continue;
}
nbusy++;
}
}
if (nbusy) {
/*
* Failed to sync all blocks. Indicate this and don't
* unmount filesystems (thus forcing an fsck on reboot).
*/
printf("giving up on %d buffers\n", nbusy);
DELAY(500); /* 5 seconds */
}
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
> This sounds very possible to me. I have been experiencing the same > error, on a system that I've been trying to set up using 5.3-RC1 and > a new 160Gbyte SATA drives My hardware is: > > atapci0: port > 0xb000-0xb00f,0xac00-0xac03,0xa800-0xa807,0xa400-0xa403,0xa000-0xa007 mem > 0xdf081000-0xdf0811ff irq 18 at device 11.0 on pci1 ad4: 152627MB > [310101/16/63] at ata2-master SATA150 > > (I notice that Michail and I both have Seagate drives ...). > > I had problems with a filesystem on a partition which crossed the > LBA=268435455 threshold. After googling and reading this thread and > Søren's posting, I tried removing the filesystem and making a little > 1000 sector partition which straddled the lba48 transition sector - I was > able to get read and write failure messages of the above form > reproducibly, by dd-ing between the test partition and /dev/zero. The same problem with similar IDE Seagate HDD: ad0: ATA-6 disk at ata0-master ad0: 152627MB (312581808 sectors), 310101 C, 16 H, 63 S, 512 B [...] ad0: FAILURE - READ_DMA status=51 error=10 LBA=268435455 It had 312581808 sectors, but failed at >= 268435455 : bash-2.05b# dd if=/dev/ad0 of=/dev/null bs=512 skip=268435453 dd: /dev/ad0: Input/output error 2+0 records in 2+0 records out 1024 bytes transferred in 0.163827 secs (6250 bytes/sec) bash-2.05b# dd if=/dev/ad0 of=/dev/null bs=512 skip=268435454 dd: /dev/ad0: Input/output error 1+0 records in 1+0 records out 512 bytes transferred in 0.156888 secs (3263 bytes/sec) bash-2.05b# dd if=/dev/ad0 of=/dev/null bs=512 skip=268435455 dd: /dev/ad0: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.149888 secs (0 bytes/sec) Decreasing the 48-bit LBA threshold by 1 really helped: bash-2.05b# dd if=/dev/ad0 bs=512 skip=312581808 0+0 records in 0+0 records out 0 bytes transferred in 0.88 secs (0 bytes/sec) bash-2.05b# dd if=/dev/ad0 bs=512 skip=312581807 1+0 records in 1+0 records out 512 bytes transferred in 0.019809 secs (25847 bytes/sec) Timestamp: 0x41826DE9 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GEOM whitepaper?
"Ryan Sommers" <[EMAIL PROTECTED]> writes: > Are there any whitepapers, documentation, etc (aside from the new book > about 5.2) on GEOM? I've been reading over the code and it would be nice > to have an annotation to go with it. http://www.google.com/search?q=phk+geom+paper DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GEOM whitepaper?
Are there any whitepapers, documentation, etc (aside from the new book about 5.2) on GEOM? I've been reading over the code and it would be nice to have an annotation to go with it. -- Ryan Sommers [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.8-STABLE kernel crash
On Thu, 28 Oct 2004 21:30:45 -0300, Allan Marshall <[EMAIL PROTECTED]> wrote: > The box has been quite unstable, with restarts every few days > this is the first dump ive got with DDB > I realize this likely isnt enough information, but if you could point me in the > right direction > I can provide anymore information required. 1) dmesg output please 2) Is this a new problem? Did the box run FreeBSD stably earlier? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0: FAILURE - WRITE_DMA
On 8th October, Mikhail P. <[EMAIL PROTECTED]> reported the error:
ad0: FAILURE - WRITE_DMA status=51 error=10
LBA=268435455
On Sun, 10 Oct 2004, Søren Schmidt wrote:
> so that leaves the disks for scrutiny. One thing to try is change the
> tripping point where we switch from 28bit mode to 48 bit mode, could be
> a 1 off error in the firmware...
This sounds very possible to me. I have been experiencing the same
error, on a system that I've been trying to set up using 5.3-RC1 and
a new 160Gbyte SATA drives My hardware is:
atapci0: port
0xb000-0xb00f,0xac00-0xac03,0xa800-0xa807,0xa400-0xa403,0xa000-0xa007 mem
0xdf081000-0xdf0811ff irq 18 at device 11.0 on pci1
ad4: 152627MB [310101/16/63] at ata2-master SATA150
(I notice that Michail and I both have Seagate drives ...).
I had problems with a filesystem on a partition which crossed the
LBA=268435455 threshold. After googling and reading this thread and
Søren's posting, I tried removing the filesystem and making a little
1000 sector partition which straddled the lba48 transition sector - I was
able to get read and write failure messages of the above form
reproducibly, by dd-ing between the test partition and /dev/zero.
I edited the /usr/src/sys/dev/ata/ata-lowlevel.c file and reduced the
48-bit trigger level by one:
--- ata-lowlevel.c.orig Fri Oct 29 12:06:09 2004
+++ ata-lowlevel.c Fri Oct 29 12:05:38 2004
@@ -700,7 +700,7 @@
ATA_IDX_OUTB(atadev->channel, ATA_ALTSTAT, ATA_A_4BIT);
/* only use 48bit addressing if needed (avoid bugs and overhead) */
-if ((lba > 268435455 || count > 256) && atadev->param &&
+if ((lba > 268435454 || count > 256) && atadev->param &&
atadev->param->support.command2 & ATA_SUPPORT_ADDRESS48) {
/* translate command into 48bit version */
and built a new kernel (I'm using the stock GENERIC configuration).
The resulting kernel was able to dd to and from the test partition
without error. I've now created a new filesystem that uses this part
of the disk and restored the contents from backup, and have been
actively using the filesystem for the last day without observing any
further problems.
Regards,
--
Neil HoggarthDepartmental Computing Manager
<[EMAIL PROTECTED]> Laboratory of Physiology
http://www.physiol.ox.ac.uk/~njh/ University of Oxford, UK
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4.8-STABLE kernel crash
The box has been quite unstable, with restarts every few days
this is the first dump ive got with DDB
I realize this likely isnt enough information, but if you could point me in the right
direction
I can provide anymore information required.
uname -a
FreeBSD *** 4.8-STABLE FreeBSD 4.8-STABLE #1: Sun Sep 19 21:04:55 GMT
2004 [EMAIL PROTECTED]:/usr/src/sys/compile/IRCD i386
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc017c3af in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2 0xc017c7d4 in poweroff_wait (junk=0xc02b182c, howto=-1070918865)
at ../../kern/kern_shutdown.c:595
#3 0xc0261e1a in trap_fatal (frame=0xf79ace3c, eva=983060)
at ../../i386/i386/trap.c:974
#4 0xc0261aed in trap_pfault (frame=0xf79ace3c, usermode=0, eva=983060)
at ../../i386/i386/trap.c:867
#5 0xc02616d7 in trap (frame={tf_fs = -1070923760, tf_es = -147914736,
tf_ds = 16973840, tf_edi = 672440320, tf_esi = 227, tf_ebp = -140849532,
tf_isp = -140849560, tf_ebx = -148367476, tf_edx = 983040,
tf_ecx = 250428367, tf_eax = 524281, tf_trapno = 12, tf_err = 0,
tf_eip = -1071494896, tf_cs = 8, tf_eflags = 66054, tf_esp = 0,
tf_ss = -140786112}) at ../../i386/i386/trap.c:466
#6 0xc0224910 in vm_page_lookup (object=0xf728178c, pindex=227)
at ../../vm/vm_page.c:515
#7 0xc021cc70 in vm_fault (map=0xf79bc640, vaddr=672440320,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:292
#8 0xc0261a82 in trap_pfault (frame=0xf79acfa8, usermode=1, eva=672441792)
at ../../i386/i386/trap.c:847
#9 0xc02615ab in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 672514096, tf_esi = 0, tf_ebp = -1077937344,
tf_isp = -140849196, tf_ebx = 672505356, tf_edx = 0, tf_ecx = 134533128,
tf_eax = 1008, tf_trapno = 12, tf_err = 4, tf_eip = 672010244,
tf_cs = 31, tf_eflags = 66054, tf_esp = -1077937368, tf_ss = 47})
at ../../i386/i386/trap.c:377
#10 0x280e1004 in ?? ()
#11 0x280e10bd in ?? ()
#12 0x280e70e5 in ?? ()
#13 0x28085174 in ?? ()
#14 0x8048f66 in ?? ()
#15 0x8048e4a in ?? ()
(kgdb)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: questionable feature in FreeBSD pmake
On Thu, 28 Oct 2004, Sean Farley wrote: SF>On Thu, 28 Oct 2004, Dan Strick wrote: SF> SF>> On Thu, 28 Oct 2004 03:23:02 -0700, Dan Strick wrote: SF>> > SF>> > I just spent a *very* frustrating hour trying to figure out why the SF>> > FreeBSD make program was invoking all commands to make things in a SF>> > subdirectory named "obj". SF> SF>I just noticed this is in the BUGS section of make: SF> The determination of .OBJDIR is contorted to the point of SF> absurdity. SF> SF>> It seems that I have no alternative but to rename my "obj" directory. SF>> Can someone suggest an alternative? Note that it is not possible for SF>> me to set an environment variable (i.e. MAKEOBJDIR) before running SF>> make or to add an option to the make command line. Any fix must be SF>> contained entirely within the makefile. Setting .OBJDIR or MAKEOBJDIR SF>> within the makefile does not work. Placing a "cd .." or "cd SF>> $(.CURDIR)" in front of every set of makefile shell commands is SF>> unthinkable. SF> SF>Why are you unable to do anything with the command-line? Any of these SF>will solve your problem. SF>Bourne: SF>MAKEOBJDIR=/no_obj_here make SF> SF>Bourne or CSH: SF>env MAKEOBJDIR=/no_obj_here make SF> SF>Here is a Makefile that does not use obj/. The special targets can be SF>placed into a file to be included into all your Makefiles. It only SF>suffers from a failed build where it will not rename obj to tmpobj. SF> SF>--- SF>.BEGIN: SF> mv tmpobj obj || mkdir obj SF> SF>.INTERRUPT: SF> mv obj tmpobj .INTERRUPT is dangerous at the moment, because it is not called always and it's sometimes called in the wrong place. I have a fix for this. harti SF> SF>.END: SF> mv obj tmpobj SF> SF>all: SF> touch testing SF> SF>clean: SF> rm -f testing SF>--- SF> SF>Sean SF> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
