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
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).
Command interrupt devices are now supported, this applie
20 matches
Mail list logo
