On Mon, 8 Mar 1999, Mike Smith wrote:
# I'd be more worried that they're going to different places _after_
# they've read the disklabel. If they couldn't read the disklabel, you
# wouldn't be mounting the disk in the first place.
#
# Is your disk dedicated in some way?
Nope not knowingly. I
> I'm going to play around with Mike's suggestion of instrumenting
> ad_interrupt with a bunch of debug prints and see if I can see
> what is happening. I'll do this right after I determine for
> sure that both the old and new driver are at least trying to
> read the same blocks from the disk for
On Mon, 8 Mar 1999, S?ren Schmidt wrote:
# > All that aside I'm willing to look closer into the possibility of
# > this being the problem. How does one go about obtaining a copy of
# > the raw disklabels? And once I have them how do I verify them for
# > correctness?
#
# Hmm, the only thing I c
It seems Steve Price wrote:
> On Sun, 7 Mar 1999, Mike Smith wrote:
>
> #
> # >From the context I've seen, the 'ufs_dirbad' panic is almost certainly
> # due to corrupted disk input.
>
> I definitely can't rule that out as a possibility, but it does make
> it difficult to explain how the old dr
> On Sun, 7 Mar 1999, Mike Smith wrote:
>
> #
> # >From the context I've seen, the 'ufs_dirbad' panic is almost certainly
> # due to corrupted disk input.
>
> I definitely can't rule that out as a possibility, but it does make
> it difficult to explain how the old driver works on this machine.
On Sun, 7 Mar 1999, Mike Smith wrote:
#
# >From the context I've seen, the 'ufs_dirbad' panic is almost certainly
# due to corrupted disk input.
I definitely can't rule that out as a possibility, but it does make
it difficult to explain how the old driver works on this machine.
I'm typing this
On Sun, 7 Mar 1999, Doug Rabson wrote:
# > Just for grins I changed the ata_probe to ignore all but the first
# > controller and it is back to the ufs_dirbad panic. :(
#
# I never had the ufs_dirbad panic. With the 4 March driver, my system
# works very well and probes all the ATA devices. Very
On Sun, 7 Mar 1999, Steve Price wrote:
> On Sun, 7 Mar 1999, Doug Rabson wrote:
>
> # > Are you sure it tries to probe the slave ??
> # > Could please try to have it printout scp->devices in ata_probe ??
> #
> # Here is a log of an attempted boot with ATA_DEBUG defined. It looks like
> # ata_pr
On Sun, 7 Mar 1999, Doug Rabson wrote:
# > Are you sure it tries to probe the slave ??
# > Could please try to have it printout scp->devices in ata_probe ??
#
# Here is a log of an attempted boot with ATA_DEBUG defined. It looks like
# ata_probe() detected a slave where there isn't one.
#
# ata
It seems Doug Rabson wrote:
> >
> > Are you sure it tries to probe the slave ??
> > Could please try to have it printout scp->devices in ata_probe ??
>
> Here is a log of an attempted boot with ATA_DEBUG defined. It looks like
> ata_probe() detected a slave where there isn't one.
>
> ata1: devi
On Sun, 7 Mar 1999, Sren Schmidt wrote:
> It seems Doug Rabson wrote:
>
> >This seems to be happening to me too on my laptop. The kernel hangs in
> >ata_command() waiting for an interrupt (ATA_WAIT_INTR) when it is trying
> >to probe the slave device on my second ide controller. Specifically, i
On Sun, 7 Mar 1999, Sren Schmidt wrote:
> It seems Doug Rabson wrote:
>
> >This seems to be happening to me too on my laptop. The kernel hangs in
> >ata_command() waiting for an interrupt (ATA_WAIT_INTR) when it is trying
> >to probe the slave device on my second ide controller. Specifically, i
It seems Doug Rabson wrote:
>This seems to be happening to me too on my laptop. The kernel hangs in
>ata_command() waiting for an interrupt (ATA_WAIT_INTR) when it is trying
>to probe the slave device on my second ide controller. Specifically, it
>is the first ata_command() in ata_get_param() wh
On Sat, 6 Mar 1999, Sren Schmidt wrote:
> It seems Steve Price wrote:
>
> [debug output omitted]
>
> I think I know what is failing now, I just have to find a fix for it..
>
> -S?ren
This seems to be happening to me too on my laptop. The kernel hangs in
ata_command() waiting for an interrupt
It seems Steve Price wrote:
[debug output omitted]
I think I know what is failing now, I just have to find a fix for it..
-Søren
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
On Fri, 5 Mar 1999, S?ren Schmidt wrote:
# It seems Steve Price wrote:
#
# >This works a little better on my machine. It doesn't panic
# >anymore more. It just hangs where it used to panic. Should
# >I turn on the DEBUG output, hand scribe the output, and send
# >it to you?
#
# That would be
It seems Steve Price wrote:
>This works a little better on my machine. It doesn't panic
>anymore more. It just hangs where it used to panic. Should
>I turn on the DEBUG output, hand scribe the output, and send
>it to you?
That would be very helpfull yes...
-Søren
To Unsubscribe: send mail
On Fri, 5 Mar 1999, S?ren Schmidt wrote:
# Second update to the new ATA/ATAPI driver:
#
# Now all actual probing of both ATA & ATAPI devices are done after
# interrupts are enabled, this kills the last "unwanted interrupts"
# (and there is no ugly hacks like in the old driver to avoid them).
# Co
19 matches
Mail list logo
