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 can
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 the
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
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 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() which
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, it
is
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, it
is
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: devices = 0xc
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.
#
#
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_probe()
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, 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, 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.
The way
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 driver
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
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 applies
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).
#
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 to
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
20 matches
Mail list logo
