Discussion:
2.6.12-rc1-mm3
(too old to reply)
Chuck Ebbert
2005-03-25 09:42:48 UTC
Permalink
Latest versions of sudsystem trees
Is that some kind of beer dispenser?

--
Chuck
http://www.counterfeitmini.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Brice Goglin
2005-03-25 10:52:30 UTC
Permalink
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/
- Mainly a bunch of fixes relative to 2.6.12-rc1-mm2.
One thing I noticed:
-mm2 did not power off my laptop (Compaq Evo N600c).
I thought I would see something like "ACPI power off" or
USB deregistration messages. But nothing appeared.

It seems to work with -mm3 now.

.config attached.

Regards,
Brice
Rafael J. Wysocki
2005-03-25 11:31:11 UTC
Permalink
Hi,
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/
- Mainly a bunch of fixes relative to 2.6.12-rc1-mm2.
First, rmmod works again (thanks ;-)).
- Again, we'd like people who have had recent DRM and USB resume problems to
test and report, please.
My box is still hanged solid on resume (swsusp) by the drivers:

ohci_hcd
ehci_hcd
yenta_socket

possibly others, too. To avoid this, I had to revert the following patch from
the Len's tree:

diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
+++ b/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
@@ -72,10 +72,12 @@
u8 active; /* Current IRQ */
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
- u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u8 initialized:1;
+ u8 suspend_resume:1;
+ u8 reserved:6;
};

struct acpi_pci_link {
@@ -530,6 +532,10 @@

ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");

+ if (link->irq.suspend_resume) {
+ acpi_pci_link_set(link, link->irq.active);
+ link->irq.suspend_resume = 0;
+ }
if (link->irq.initialized)
return_VALUE(0);

@@ -713,38 +719,24 @@
return_VALUE(result);
}

-
-static int
-acpi_pci_link_resume (
- struct acpi_pci_link *link)
-{
- ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
-
- if (link->irq.active && link->irq.initialized)
- return_VALUE(acpi_pci_link_set(link, link->irq.active));
- else
- return_VALUE(0);
-}
-
-
static int
-irqrouter_resume(
- struct sys_device *dev)
+irqrouter_suspend(
+ struct sys_device *dev,
+ u32 state)
{
struct list_head *node = NULL;
struct acpi_pci_link *link = NULL;

- ACPI_FUNCTION_TRACE("irqrouter_resume");
+ ACPI_FUNCTION_TRACE("irqrouter_suspend");

list_for_each(node, &acpi_link.entries) {
-
link = list_entry(node, struct acpi_pci_link, node);
if (!link) {
ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
continue;
}
-
- acpi_pci_link_resume(link);
+ if (link->irq.active && link->irq.initialized)
+ link->irq.suspend_resume = 1;
}
return_VALUE(0);
}
@@ -856,7 +848,7 @@

static struct sysdev_class irqrouter_sysdev_class = {
set_kset_name("irqrouter"),
- .resume = irqrouter_resume,
+ .suspend = irqrouter_suspend,
};


# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/18 16:30:29-05:00 ***@intel.com
# [ACPI] S3 Suspend to RAM: interrupt resume fix
#
# Delete PCI Interrupt Link Device .resume method --
# it is the device driver's job to request interrupts,
# not the Link's job to remember what the devices want.
#
# This addresses the issue of attempting to run
# the ACPI interpreter too early in resume, when
# interrupts are still disabled.
#
# http://bugzilla.kernel.org/show_bug.cgi?id=3469
#
# Signed-off-by: David Shaohua Li <***@intel.com>
# Signed-off-by: Len Brown <***@intel.com>
#
# drivers/acpi/pci_link.c
# 2005/03/02 22:23:50-05:00 ***@intel.com +14 -22
# Delete PCI Interrupt Link .resume method
#

Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Li, Shaohua
2005-03-25 12:57:34 UTC
Permalink
Hi,
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-
rc1/2.6.12-rc1-mm3/
- Mainly a bunch of fixes relative to 2.6.12-rc1-mm2.
First, rmmod works again (thanks ;-)).
- Again, we'd like people who have had recent DRM and USB resume
problems
to
test and report, please.
ohci_hcd
ehci_hcd
yenta_socket
possibly others, too. To avoid this, I had to revert the following
patch
from
diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
+++ b/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
@@ -72,10 +72,12 @@
u8 active; /* Current IRQ
*/
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
- u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u8 initialized:1;
+ u8 suspend_resume:1;
+ u8 reserved:6;
};
struct acpi_pci_link {
@@ -530,6 +532,10 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
+ if (link->irq.suspend_resume) {
+ acpi_pci_link_set(link, link->irq.active);
+ link->irq.suspend_resume = 0;
+ }
if (link->irq.initialized)
return_VALUE(0);
+ acpi_pci_link_set(link, link->irq.active);
Thanks,
Shaohua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Rafael J. Wysocki
2005-03-25 14:22:26 UTC
Permalink
Hi,

On Friday, 25 of March 2005 13:54, you wrote:
]--snip--[
Post by Rafael J. Wysocki
ohci_hcd
ehci_hcd
yenta_socket
possibly others, too. To avoid this, I had to revert the following
diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
+++ b/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
@@ -72,10 +72,12 @@
u8 active; /* Current IRQ
*/
Post by Rafael J. Wysocki
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
- u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u8 initialized:1;
+ u8 suspend_resume:1;
+ u8 reserved:6;
};
struct acpi_pci_link {
@@ -530,6 +532,10 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
+ if (link->irq.suspend_resume) {
+ acpi_pci_link_set(link, link->irq.active);
+ link->irq.suspend_resume = 0;
+ }
if (link->irq.initialized)
return_VALUE(0);
+ acpi_pci_link_set(link, link->irq.active);
You mean apply the patch again and remove just the single
line? No effect (ie hangs).

Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Rafael J. Wysocki
2005-03-26 19:09:43 UTC
Permalink
Hi,
Post by Rafael J. Wysocki
]--snip--[
Post by Rafael J. Wysocki
ohci_hcd
ehci_hcd
yenta_socket
possibly others, too. To avoid this, I had to revert the following
diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
+++ b/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
@@ -72,10 +72,12 @@
u8 active; /* Current IRQ
*/
Post by Rafael J. Wysocki
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
- u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u8 initialized:1;
+ u8 suspend_resume:1;
+ u8 reserved:6;
};
struct acpi_pci_link {
@@ -530,6 +532,10 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
+ if (link->irq.suspend_resume) {
+ acpi_pci_link_set(link, link->irq.active);
+ link->irq.suspend_resume = 0;
+ }
if (link->irq.initialized)
return_VALUE(0);
+ acpi_pci_link_set(link, link->irq.active);
You mean apply the patch again and remove just the single
line? No effect (ie hangs).
It looks like removing this line couldn't help.
Apparently, acpi_pci_link_set(link, link->irq.active) must be called
_before_ the call to pci_write_config_word() in
drivers/pci/pci.c:pci_set_power_state(), because the box hangs
otherwise. However, with the patch applied,
acpi_pci_link_set(link, link->irq.active) is only called through
pcibios_enable_irq() in pcibios_enable_device(), which is _after_
the call to pci_set_power_state() in pci_enable_device_bars(),
so it's too late.
Hence, it seems, if you really want to get rid of the
irqrouter_resume(), whatever the reason, the simplest fix
seems to be to change the order of calls to pci_set_power_state()
Sorry, forget it. It was a good theory that didn't work.

It seems that we have to set all of the PCI links or at least some
of them before we start calling pci_set_power_state().

Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Rafael J. Wysocki
2005-03-26 18:25:34 UTC
Permalink
Hi,
Post by Rafael J. Wysocki
]--snip--[
Post by Rafael J. Wysocki
ohci_hcd
ehci_hcd
yenta_socket
possibly others, too. To avoid this, I had to revert the following
diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
+++ b/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
@@ -72,10 +72,12 @@
u8 active; /* Current IRQ
*/
Post by Rafael J. Wysocki
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
- u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u8 initialized:1;
+ u8 suspend_resume:1;
+ u8 reserved:6;
};
struct acpi_pci_link {
@@ -530,6 +532,10 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
+ if (link->irq.suspend_resume) {
+ acpi_pci_link_set(link, link->irq.active);
+ link->irq.suspend_resume = 0;
+ }
if (link->irq.initialized)
return_VALUE(0);
+ acpi_pci_link_set(link, link->irq.active);
You mean apply the patch again and remove just the single
line? No effect (ie hangs).
It looks like removing this line couldn't help.

Apparently, acpi_pci_link_set(link, link->irq.active) must be called
_before_ the call to pci_write_config_word() in
drivers/pci/pci.c:pci_set_power_state(), because the box hangs
otherwise. However, with the patch applied,
acpi_pci_link_set(link, link->irq.active) is only called through
pcibios_enable_irq() in pcibios_enable_device(), which is _after_
the call to pci_set_power_state() in pci_enable_device_bars(),
so it's too late.

Hence, it seems, if you really want to get rid of the
irqrouter_resume(), whatever the reason, the simplest fix
seems to be to change the order of calls to pci_set_power_state()
and pcibios_enable_device() in pci_enable_device_bars():

--- old/drivers/pci/pci.c 2005-03-26 19:10:09.000000000 +0100
+++ linux-2.6.12-rc1-mm2/drivers/pci/pci.c 2005-03-26 19:10:54.000000000 +0100
@@ -442,9 +442,9 @@ pci_enable_device_bars(struct pci_dev *d
{
int err;

- pci_set_power_state(dev, PCI_D0);
if ((err = pcibios_enable_device(dev, bars)) < 0)
return err;
+ pci_set_power_state(dev, PCI_D0);
return 0;
}

though I'm not sure if that's legal.

Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Li Shaohua
2005-03-28 01:27:23 UTC
Permalink
Hi,
Post by Rafael J. Wysocki
]--snip--[
Post by Rafael J. Wysocki
ohci_hcd
ehci_hcd
yenta_socket
possibly others, too. To avoid this, I had to revert the following
diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
+++ b/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
@@ -72,10 +72,12 @@
u8 active; /* Current IRQ
*/
Post by Rafael J. Wysocki
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
- u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u8 initialized:1;
+ u8 suspend_resume:1;
+ u8 reserved:6;
};
struct acpi_pci_link {
@@ -530,6 +532,10 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
+ if (link->irq.suspend_resume) {
+ acpi_pci_link_set(link, link->irq.active);
+ link->irq.suspend_resume = 0;
+ }
if (link->irq.initialized)
return_VALUE(0);
+ acpi_pci_link_set(link, link->irq.active);
You mean apply the patch again and remove just the single
line? No effect (ie hangs).
It looks like removing this line couldn't help.
Apparently, acpi_pci_link_set(link, link->irq.active) must be called
_before_ the call to pci_write_config_word() in
drivers/pci/pci.c:pci_set_power_state(), because the box hangs
otherwise. However, with the patch applied,
acpi_pci_link_set(link, link->irq.active) is only called through
pcibios_enable_irq() in pcibios_enable_device(), which is _after_
the call to pci_set_power_state() in pci_enable_device_bars(),
so it's too late.
Hence, it seems, if you really want to get rid of the
irqrouter_resume(), whatever the reason, the simplest fix
seems to be to change the order of calls to pci_set_power_state()
--- old/drivers/pci/pci.c 2005-03-26 19:10:09.000000000 +0100
+++ linux-2.6.12-rc1-mm2/drivers/pci/pci.c 2005-03-26 19:10:54.000000000 +0100
@@ -442,9 +442,9 @@ pci_enable_device_bars(struct pci_dev *d
{
int err;
- pci_set_power_state(dev, PCI_D0);
if ((err = pcibios_enable_device(dev, bars)) < 0)
return err;
+ pci_set_power_state(dev, PCI_D0);
return 0;
}
though I'm not sure if that's legal.
Hmm, no, pci_set_power_state should be called before
pcibios_enable_device, otherwise enable_device may fail. This is very
strange. In boot time, there also are uninitialized link devices, I'm
wonder why the call of pci_enable_device_bars doesn't fail in boot time.
Did you find the bug only in specific system?

Could you please file a bug in bugzilla? I don't want to lose the
context of thread. And please attach your acpidmp output in the bug.

Thanks,
Shaohua

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Rafael J. Wysocki
2005-03-29 10:43:55 UTC
Permalink
Hi,
]--snip--[
Post by Li Shaohua
Could you please file a bug in bugzilla? I don't want to lose the
context of thread. And please attach your acpidmp output in the bug.
The bug report is at:

http://bugzilla.kernel.org/show_bug.cgi?id=4416

I've put there all the information related to it that I've already collected.

Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Borislav Petkov
2005-03-25 17:04:59 UTC
Permalink
Hi Andrew,

mm3 still not booting on my machine. Boot option 'nmi_watchdog=2' (my cpu is a
dual core pentium 4 HT, 2.60 GHz) gets me a bit further in the boot process
but it blocks there too.

[output retyped from screen]:
kernel: [ 4.109241] PM: Checking swsusp image.
kernel: [ 4.109244] PM: Resume from disk failed.
kernel: [ 4.112220] VFS: Mounted root (ext2 filesystem) readonly.
kernel: [ 4.112465] Freeing unused kernel memory: 188k freed
kernel: [ 4.142002] logips2pp: Detected unknown logitech mouse model 1
kernel: [ 4.274620] input: PS/2 Logitech Mouse on isa0060/serio1
<--- [point of previous blocks without boot option 'nmi_watchdog=2']--->
INIT: version 2.86 booting
Mounting a tmpfs over /dev... done.
Creating initial device nodes... done.
Setting parameters of disc: (none).
Activating swap.
kernel: [ 10.712648] Adding 976744k swap on /dev/hda2. Priority:-1 extents:1
Checking root file system...
fsck 1.36 (05-Feb-2005)
/: clean, 127290/1831424 files, 898566/3662056 blocks
[EOF]

Regards,
Boris.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Barry K. Nathan
2005-03-25 18:20:52 UTC
Permalink
More fixlets derived from the Coverity tool (does this thing have a name?)
AFAICT the name of the tool is "Coverity Prevent". (But I'm not
absolutely 100% sure.)

-Barry K. Nathan <***@pobox.com>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Steven Cole
2005-03-25 19:53:16 UTC
Permalink
I'm having trouble reading from the cd-rom with 2.6.12-rc1-mm3.

Kernel 2.6.12-rc1 behaves normally:

[***@spc1 steven]# mount /dev/hdc /mnt/cdrom
mount: block device /dev/hdc is write-protected, mounting read-only
[***@spc1 steven]# df -T
Filesystem Type Size Used Avail Use% Mounted on
/dev/hda1 ext3 304M 96M 193M 34% /
/dev/hda9 reiserfs 8.3G 7.2G 1.1G 88% /home
/dev/hda8 ext3 464M 8.1M 432M 2% /tmp
/dev/hda6 ext3 7.4G 1.5G 5.5G 22% /usr
/dev/hda7 ext3 1.9G 96M 1.7G 6% /var
/dev/hdc iso9660 38M 38M 0 100% /mnt/cdrom
[***@spc1 steven]# ls -l /mnt/cdrom
total 37859
-rw-r--r-- 1 501 501 38673949 Mar 25 07:41 linux-2429tar.gz
-rw-r--r-- 1 501 501 92317 Mar 25 07:43 patch-2430-rc1.bz2
[***@spc1 steven]# uname -r
2.6.12-rc1-GX110

Snipped from dmesg:

[ 51.440018] EXT3-fs: mounted filesystem with ordered data mode.
[ 58.585093] PCI: Found IRQ 5 for device 0000:01:0c.0
[ 232.333180] ISO 9660 Extensions: IEEE_P1282

Kernel 2.6.12-rc1-mm3 does not: (same CD left in device)

[***@spc1 steven]# mount /dev/hdc /mnt/cdrom
mount: block device /dev/hdc is write-protected, mounting read-only
[***@spc1 steven]# df -T
Filesystem Type Size Used Avail Use% Mounted on
/dev/hda1 ext3 304M 96M 193M 34% /
/dev/hda9 reiserfs 8.3G 7.2G 1.1G 88% /home
/dev/hda8 ext3 464M 8.1M 432M 2% /tmp
/dev/hda6 ext3 7.4G 1.5G 5.5G 22% /usr
/dev/hda7 ext3 1.9G 96M 1.7G 6% /var
/dev/hdc iso9660 38M 38M 0 100% /mnt/cdrom
[***@spc1 steven]# ls -l /mnt/cdrom
total 0
[***@spc1 steven]# uname -r
2.6.12-rc1-mm3-GX110

Snipped from dmesg:

[ 49.198779] EXT3-fs: mounted filesystem with ordered data mode.
[ 56.310394] PCI: Found IRQ 5 for device 0000:01:0c.0
[ 222.804956] rock: directory entry would overflow storage
[ 222.804978] rock: sig=0x5245, size=8, remaining=0
[ 235.551953] rock: directory entry would overflow storage
[ 235.551969] rock: sig=0x5850, size=36, remaining=34
[ 235.551976] rock: directory entry would overflow storage
[ 235.551981] rock: sig=0x5850, size=36, remaining=34

Sorry, I don't have the time to do further troubleshooting, but I
hope this is enough information. The .config for this machine was
posted earlier in another thread here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111167720523853&w=2

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Andrew Morton
2005-03-25 20:31:53 UTC
Permalink
Post by Steven Cole
[ 49.198779] EXT3-fs: mounted filesystem with ordered data mode.
[ 56.310394] PCI: Found IRQ 5 for device 0000:01:0c.0
[ 222.804956] rock: directory entry would overflow storage
[ 222.804978] rock: sig=0x5245, size=8, remaining=0
[ 235.551953] rock: directory entry would overflow storage
[ 235.551969] rock: sig=0x5850, size=36, remaining=34
[ 235.551976] rock: directory entry would overflow storage
[ 235.551981] rock: sig=0x5850, size=36, remaining=34
Sorry, I don't have the time to do further troubleshooting, but I
hope this is enough information. The .config for this machine was
http://marc.theaimsgroup.com/?l=linux-kernel&m=111167720523853&w=2
Steven
I found a few more minutes to test two more kernels. The problem
2.6.12-rc1 reads the cd-rom OK as reported earlier
2.6.12-rc1-mm1 also reads the cd-rom OK
2.6.12-rc1-mm2 broken same as -mm3 described as above
2.6.12-rc1-mm3 broken as reported earlier
Are you really really sure about that? -mm3 included both the bk-ide-dev
tree and the isofs changes. 2.6.12-rc1-mm2 had neither.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Steven Cole
2005-03-25 21:27:04 UTC
Permalink
Post by Andrew Morton
Post by Steven Cole
[ 49.198779] EXT3-fs: mounted filesystem with ordered data mode.
[ 56.310394] PCI: Found IRQ 5 for device 0000:01:0c.0
[ 222.804956] rock: directory entry would overflow storage
[ 222.804978] rock: sig=0x5245, size=8, remaining=0
[ 235.551953] rock: directory entry would overflow storage
[ 235.551969] rock: sig=0x5850, size=36, remaining=34
[ 235.551976] rock: directory entry would overflow storage
[ 235.551981] rock: sig=0x5850, size=36, remaining=34
Sorry, I don't have the time to do further troubleshooting, but I
hope this is enough information. The .config for this machine was
http://marc.theaimsgroup.com/?l=linux-kernel&m=111167720523853&w=2
Steven
I found a few more minutes to test two more kernels. The problem
2.6.12-rc1 reads the cd-rom OK as reported earlier
2.6.12-rc1-mm1 also reads the cd-rom OK
2.6.12-rc1-mm2 broken same as -mm3 described as above
2.6.12-rc1-mm3 broken as reported earlier
Are you really really sure about that? -mm3 included both the bk-ide-dev
tree and the isofs changes. 2.6.12-rc1-mm2 had neither.
Just to be really really sure, I repeated the tests. I even checked
that the image/label combination in /etc/lilo.conf was what I intended,
but the uname -r should show what's what.

Same results, -mm2 broken, and -mm1 reads the disk. I even tried
other CD's just to make sure I didn't have something weird. Same results.

[***@spc1 steven]# uname -r
2.6.12-rc1-mm2-GX110
[***@spc1 steven]# mount /dev/hdc /mnt/cdrom
mount: block device /dev/hdc is write-protected, mounting read-only
[***@spc1 steven]# df -T
Filesystem Type Size Used Avail Use% Mounted on
/dev/hda1 ext3 304M 96M 193M 34% /
/dev/hda9 reiserfs 8.3G 7.5G 818M 91% /home
/dev/hda8 ext3 464M 8.1M 432M 2% /tmp
/dev/hda6 ext3 7.4G 1.5G 5.5G 22% /usr
/dev/hda7 ext3 1.9G 96M 1.7G 6% /var
/dev/hdc iso9660 2.9M 2.9M 0 100% /mnt/cdrom
[***@spc1 steven]# ls -l /mnt/cdrom
total 0
[***@spc1 steven]# dmesg | tail
[ 51.205871] EXT3 FS on hda6, internal journal
[ 51.205880] EXT3-fs: mounted filesystem with ordered data mode.
[ 51.234132] kjournald starting. Commit interval 5 seconds
[ 51.234544] EXT3 FS on hda7, internal journal
[ 51.234553] EXT3-fs: mounted filesystem with ordered data mode.
[ 58.357329] PCI: Found IRQ 5 for device 0000:01:0c.0
[ 146.301026] rock: directory entry would overflow storage
[ 146.301044] rock: sig=0x5245, size=8, remaining=0
[ 158.388397] rock: directory entry would overflow storage
[ 158.388415] rock: sig=0x5850, size=36, remaining=34
[***@spc1 steven]#

Machine rebooted here.

[***@spc1 steven]# uname -r
2.6.12-rc1-mm1-GX110
[***@spc1 steven]# mount /dev/hdc /mnt/cdrom
mount: block device /dev/hdc is write-protected, mounting read-only
[***@spc1 steven]# df -T
Filesystem Type Size Used Avail Use% Mounted on
/dev/hda1 ext3 304M 96M 193M 34% /
/dev/hda9 reiserfs 8.3G 7.5G 818M 91% /home
/dev/hda8 ext3 464M 8.1M 432M 2% /tmp
/dev/hda6 ext3 7.4G 1.5G 5.5G 22% /usr
/dev/hda7 ext3 1.9G 96M 1.7G 6% /var
/dev/hdc iso9660 2.9M 2.9M 0 100% /mnt/cdrom
[***@spc1 steven]# ls -l /mnt/cdrom
total 2578
-rw-rw-rw- 1 501 501 2639360 Aug 7 2003 snmp-opc server 30.msi
[***@spc1 steven]# dmesg | tail
[ 50.267382] EXT3 FS on hda8, internal journal
[ 50.267395] EXT3-fs: mounted filesystem with ordered data mode.
[ 50.301423] kjournald starting. Commit interval 5 seconds
[ 50.301763] EXT3 FS on hda6, internal journal
[ 50.301774] EXT3-fs: mounted filesystem with ordered data mode.
[ 50.330087] kjournald starting. Commit interval 5 seconds
[ 50.330503] EXT3 FS on hda7, internal journal
[ 50.330516] EXT3-fs: mounted filesystem with ordered data mode.
[ 57.453061] PCI: Found IRQ 5 for device 0000:01:0c.0
[ 187.450836] ISO 9660 Extensions: IEEE_P1282
[***@spc1 steven]#

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Andrew Morton
2005-03-25 21:51:28 UTC
Permalink
Post by Steven Cole
Post by Andrew Morton
I found a few more minutes to test two more kernels. The problem
2.6.12-rc1 reads the cd-rom OK as reported earlier
2.6.12-rc1-mm1 also reads the cd-rom OK
2.6.12-rc1-mm2 broken same as -mm3 described as above
2.6.12-rc1-mm3 broken as reported earlier
Are you really really sure about that? -mm3 included both the bk-ide-dev
tree and the isofs changes. 2.6.12-rc1-mm2 had neither.
Just to be really really sure, I repeated the tests. I even checked
that the image/label combination in /etc/lilo.conf was what I intended,
but the uname -r should show what's what.
Same results, -mm2 broken, and -mm1 reads the disk. I even tried
other CD's just to make sure I didn't have something weird. Same results.
OK, thanks.

It would be interesting to copy a CD to hard disk (under -mm1) and see if
it works OK with the loopback driver.

Also, boot into -mm2 and do a `cmp' of the cdrom with the image which is on
hard-disk.

This should help us work out whether it's isofs, the driver, the VFS or
whatever.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Steven Cole
2005-03-25 22:45:36 UTC
Permalink
Post by Andrew Morton
Post by Steven Cole
Post by Andrew Morton
I found a few more minutes to test two more kernels. The problem
2.6.12-rc1 reads the cd-rom OK as reported earlier
2.6.12-rc1-mm1 also reads the cd-rom OK
2.6.12-rc1-mm2 broken same as -mm3 described as above
2.6.12-rc1-mm3 broken as reported earlier
Are you really really sure about that? -mm3 included both the bk-ide-dev
tree and the isofs changes. 2.6.12-rc1-mm2 had neither.
Just to be really really sure, I repeated the tests. I even checked
that the image/label combination in /etc/lilo.conf was what I intended,
but the uname -r should show what's what.
Same results, -mm2 broken, and -mm1 reads the disk. I even tried
other CD's just to make sure I didn't have something weird. Same results.
OK, thanks.
It would be interesting to copy a CD to hard disk (under -mm1) and see if
it works OK with the loopback driver.
Also, boot into -mm2 and do a `cmp' of the cdrom with the image which is on
hard-disk.
This should help us work out whether it's isofs, the driver, the VFS or
whatever.
-
It seems that I've run out of time here today. If this is still an issue
after the weekend, I'll do the above tests.

Until then, Happy Easter.

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jason Munro
2005-03-25 21:56:51 UTC
Permalink
Post by Steven Cole
Same results, -mm2 broken, and -mm1 reads the disk. I even tried
other CD's just to make sure I didn't have something weird. Same results.
[ 51.205871] EXT3 FS on hda6, internal journal
[ 51.205880] EXT3-fs: mounted filesystem with ordered data mode.
[ 51.234132] kjournald starting. Commit interval 5 seconds
[ 51.234544] EXT3 FS on hda7, internal journal
[ 51.234553] EXT3-fs: mounted filesystem with ordered data mode.
[ 58.357329] PCI: Found IRQ 5 for device 0000:01:0c.0
[ 146.301026] rock: directory entry would overflow storage
[ 146.301044] rock: sig=0x5245, size=8, remaining=0
[ 158.388397] rock: directory entry would overflow storage
[ 158.388415] rock: sig=0x5850, size=36, remaining=34
Same results with mm3 here, though mm2 will not boot on my machine so I'm
not sure about that. 2.6.12-rc1 works fine, rc1-mm3 successfully mounts the
cdrom device but shows no contents. Releveant dmsesg output:

rock: directory entry would overflow storage
rock: sig=0x4543, size=28, remaining=0
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=27
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=26
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=27
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=26
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=26
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=26
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=27
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=26
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=26
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=26
rock: directory entry would overflow storage
rock: sig=0x5850, size=36, remaining=27

The machine is a Toshiba P35-S609 laptop the cdrom device is:
MATSHITADVD-RAM UJ-820S, ATAPI CD/DVD-ROM drive

Kernel config is attached.

\__ Jason Munro
\__ ***@stdbev.com
\__ http://hastymail.sourceforge.net/
Andrew Morton
2005-03-25 22:17:51 UTC
Permalink
(Please dont' edit the cc line. Just do reply-to-all)
Post by Jason Munro
Post by Steven Cole
[ 146.301026] rock: directory entry would overflow storage
[ 146.301044] rock: sig=0x5245, size=8, remaining=0
[ 158.388397] rock: directory entry would overflow storage
[ 158.388415] rock: sig=0x5850, size=36, remaining=34
Same results with mm3 here, though mm2 will not boot on my machine so I'm
not sure about that. 2.6.12-rc1 works fine, rc1-mm3 successfully mounts the
rock: directory entry would overflow storage
rock: sig=0x4543, size=28, remaining=0
rock: directory entry would overflow storage
Seems that I am unable to read. It's the new rock-ridge bounds checking.

It worked for me. Is someone able to get an image of a failing filesystem
into my hands?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Chris Wright
2005-03-25 22:36:50 UTC
Permalink
Post by Andrew Morton
(Please dont' edit the cc line. Just do reply-to-all)
Post by Jason Munro
Post by Steven Cole
[ 146.301026] rock: directory entry would overflow storage
[ 146.301044] rock: sig=0x5245, size=8, remaining=0
[ 158.388397] rock: directory entry would overflow storage
[ 158.388415] rock: sig=0x5850, size=36, remaining=34
Same results with mm3 here, though mm2 will not boot on my machine so I'm
not sure about that. 2.6.12-rc1 works fine, rc1-mm3 successfully mounts the
rock: directory entry would overflow storage
rock: sig=0x4543, size=28, remaining=0
rock: directory entry would overflow storage
Seems that I am unable to read. It's the new rock-ridge bounds checking.
It worked for me. Is someone able to get an image of a failing filesystem
into my hands?
I'm interested as well. It should only be the last in the series.
Does reverting it allow the CD to work? (I'm trying to make sure the
other overflow check in the series isn't breaking things, I doubt is,
but...).

ftp.kernel.org:/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/broken-out/rock-handle-directory-overflows.patch

thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jason Munro
2005-03-25 23:01:02 UTC
Permalink
Post by Andrew Morton
It's the new rock-ridge bounds checking.
Try this, please?
diff -puN fs/isofs/rock.c~rock-handle-directory-overflows-fix
fs/isofs/rock.c --- 25/fs/isofs/rock.c~rock-handle-directory-overflows
-fix Fri Mar 25 14:21:32 2005
+++ 25-akpm/fs/isofs/rock.c Fri Mar 25 14:22:01 2005
if (rr->len < 3)
goto out; /* Something got screwed up here */
sig = isonum_721(rs.chr);
+ if (rock_check_overflow(&rs, sig))
+ goto eio;
rs.chr += rr->len;
rs.len -= rr->len;
if (rs.len < 0)
goto eio; /* corrupted isofs */
- if (rock_check_overflow(&rs, sig))
- goto eio;
switch (sig) {
if (rr->len < 3)
goto out; /* Something got screwed up here */
sig = isonum_721(rs.chr);
+ if (rock_check_overflow(&rs, sig))
+ goto eio;
rs.chr += rr->len;
rs.len -= rr->len;
if (rs.len < 0)
goto eio; /* corrupted isofs */
- if (rock_check_overflow(&rs, sig))
- goto eio;
switch (sig) {
#ifndef CONFIG_ZISOFS /* No flag for SF or ZF */
if (rr->len < 3)
goto out; /* Something got screwed up here */
sig = isonum_721(rs.chr);
+ if (rock_check_overflow(&rs, sig))
+ goto out;
rs.chr += rr->len;
rs.len -= rr->len;
if (rs.len < 0)
goto out; /* corrupted isofs */
- if (rock_check_overflow(&rs, sig))
- goto out;
switch (sig) {
_
This fixes it here.

\__ Jason Munro
\__ ***@stdbev.com
\__ http://hastymail.sourceforge.net/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Andrew Morton
2005-03-25 23:04:51 UTC
Permalink
Post by Jason Munro
This fixes it here.
The patch fixed it for me. Wheee.
OK, thanks guys. You're the best.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jason Munro
2005-03-25 22:36:50 UTC
Permalink
Post by Andrew Morton
(Please dont' edit the cc line. Just do reply-to-all)
Oops, reply-to-all it is.
Post by Andrew Morton
Post by Jason Munro
Post by Steven Cole
[ 146.301026] rock: directory entry would overflow storage
[ 146.301044] rock: sig=0x5245, size=8, remaining=0
[ 158.388397] rock: directory entry would overflow storage
[ 158.388415] rock: sig=0x5850, size=36, remaining=34
Same results with mm3 here, though mm2 will not boot on my
machine so I'm not sure about that. 2.6.12-rc1 works fine,
rc1-mm3 successfully mounts the cdrom device but shows no
rock: directory entry would overflow storage
rock: sig=0x4543, size=28, remaining=0
rock: directory entry would overflow storage
Seems that I am unable to read. It's the new rock-ridge bounds checking.
It worked for me. Is someone able to get an image of a failing
filesystem into my hands?
mkdir temp
touch temp/file1 temp/file2 temp/file3
mkisofs -R -l temp > test.iso
mount -o loop /mnt/loop
Of course that should be: mount -o loop test.iso /mnt/loop :)

\__ Jason Munro
\__ ***@stdbev.com
\__ http://hastymail.sourceforge.net/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jason Munro
2005-03-25 22:33:41 UTC
Permalink
Post by Andrew Morton
(Please dont' edit the cc line. Just do reply-to-all)
Oops, reply-to-all it is.
Post by Andrew Morton
Post by Jason Munro
Post by Steven Cole
[ 146.301026] rock: directory entry would overflow storage
[ 146.301044] rock: sig=0x5245, size=8, remaining=0
[ 158.388397] rock: directory entry would overflow storage
[ 158.388415] rock: sig=0x5850, size=36, remaining=34
Same results with mm3 here, though mm2 will not boot on my machine
so I'm not sure about that. 2.6.12-rc1 works fine, rc1-mm3
successfully mounts the cdrom device but shows no contents.
rock: directory entry would overflow storage
rock: sig=0x4543, size=28, remaining=0
rock: directory entry would overflow storage
Seems that I am unable to read. It's the new rock-ridge bounds checking.
It worked for me. Is someone able to get an image of a failing
filesystem into my hands?
I can reproduce it with the following:

mkdir temp
touch temp/file1 temp/file2 temp/file3
mkisofs -R -l temp > test.iso
mount -o loop /mnt/loop

\__ Jason Munro
\__ ***@stdbev.com
\__ http://hastymail.sourceforge.net/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Steven Cole
2005-03-25 22:53:23 UTC
Permalink
Post by Andrew Morton
It's the new rock-ridge bounds checking.
Try this, please?
OK, you caught me just as I was headed out the door. ;)

The patch fixed it for me. Wheee.

[***@spc1 steven]# uname -r
2.6.12-rc1-mm3-GX110
[***@spc1 steven]# mount /dev/hdc /mnt/cdrom
mount: block device /dev/hdc is write-protected, mounting read-only
[***@spc1 steven]# df -T
Filesystem Type Size Used Avail Use% Mounted on
/dev/hda1 ext3 304M 96M 193M 34% /
/dev/hda9 reiserfs 8.3G 7.9G 335M 97% /home
/dev/hda8 ext3 464M 8.1M 432M 2% /tmp
/dev/hda6 ext3 7.4G 1.5G 5.5G 22% /usr
/dev/hda7 ext3 1.9G 97M 1.7G 6% /var
/dev/hdc iso9660 2.9M 2.9M 0 100% /mnt/cdrom
[***@spc1 steven]# ls -l /mnt/cdrom
total 2578
-rw-rw-rw- 1 501 501 2639360 Aug 7 2003 snmp-opc server 30.msi
[***@spc1 steven]# dmesg | tail
[ 49.932278] EXT3 FS on hda8, internal journal
[ 49.932292] EXT3-fs: mounted filesystem with ordered data mode.
[ 49.966250] kjournald starting. Commit interval 5 seconds
[ 49.966659] EXT3 FS on hda6, internal journal
[ 49.966669] EXT3-fs: mounted filesystem with ordered data mode.
[ 49.994929] kjournald starting. Commit interval 5 seconds
[ 49.995334] EXT3 FS on hda7, internal journal
[ 49.995345] EXT3-fs: mounted filesystem with ordered data mode.
[ 57.117794] PCI: Found IRQ 5 for device 0000:01:0c.0
[ 123.944869] ISO 9660 Extensions: IEEE_P1282

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Andrew Morton
2005-03-25 22:29:22 UTC
Permalink
Post by Andrew Morton
It's the new rock-ridge bounds checking.
Try this, please?

diff -puN fs/isofs/rock.c~rock-handle-directory-overflows-fix fs/isofs/rock.c
--- 25/fs/isofs/rock.c~rock-handle-directory-overflows-fix Fri Mar 25 14:21:32 2005
+++ 25-akpm/fs/isofs/rock.c Fri Mar 25 14:22:01 2005
@@ -218,12 +218,12 @@ repeat:
if (rr->len < 3)
goto out; /* Something got screwed up here */
sig = isonum_721(rs.chr);
+ if (rock_check_overflow(&rs, sig))
+ goto eio;
rs.chr += rr->len;
rs.len -= rr->len;
if (rs.len < 0)
goto eio; /* corrupted isofs */
- if (rock_check_overflow(&rs, sig))
- goto eio;

switch (sig) {
case SIG('R', 'R'):
@@ -316,12 +316,12 @@ repeat:
if (rr->len < 3)
goto out; /* Something got screwed up here */
sig = isonum_721(rs.chr);
+ if (rock_check_overflow(&rs, sig))
+ goto eio;
rs.chr += rr->len;
rs.len -= rr->len;
if (rs.len < 0)
goto eio; /* corrupted isofs */
- if (rock_check_overflow(&rs, sig))
- goto eio;

switch (sig) {
#ifndef CONFIG_ZISOFS /* No flag for SF or ZF */
@@ -694,12 +694,12 @@ repeat:
if (rr->len < 3)
goto out; /* Something got screwed up here */
sig = isonum_721(rs.chr);
+ if (rock_check_overflow(&rs, sig))
+ goto out;
rs.chr += rr->len;
rs.len -= rr->len;
if (rs.len < 0)
goto out; /* corrupted isofs */
- if (rock_check_overflow(&rs, sig))
- goto out;

switch (sig) {
case SIG('R', 'R'):
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Steven Cole
2005-03-25 20:20:52 UTC
Permalink
Post by Steven Cole
I'm having trouble reading from the cd-rom with 2.6.12-rc1-mm3.
mount: block device /dev/hdc is write-protected, mounting read-only
Filesystem Type Size Used Avail Use% Mounted on
/dev/hda1 ext3 304M 96M 193M 34% /
/dev/hda9 reiserfs 8.3G 7.2G 1.1G 88% /home
/dev/hda8 ext3 464M 8.1M 432M 2% /tmp
/dev/hda6 ext3 7.4G 1.5G 5.5G 22% /usr
/dev/hda7 ext3 1.9G 96M 1.7G 6% /var
/dev/hdc iso9660 38M 38M 0 100% /mnt/cdrom
total 37859
-rw-r--r-- 1 501 501 38673949 Mar 25 07:41 linux-2429tar.gz
-rw-r--r-- 1 501 501 92317 Mar 25 07:43 patch-2430-rc1.bz2
2.6.12-rc1-GX110
[ 51.440018] EXT3-fs: mounted filesystem with ordered data mode.
[ 58.585093] PCI: Found IRQ 5 for device 0000:01:0c.0
[ 232.333180] ISO 9660 Extensions: IEEE_P1282
Kernel 2.6.12-rc1-mm3 does not: (same CD left in device)
mount: block device /dev/hdc is write-protected, mounting read-only
Filesystem Type Size Used Avail Use% Mounted on
/dev/hda1 ext3 304M 96M 193M 34% /
/dev/hda9 reiserfs 8.3G 7.2G 1.1G 88% /home
/dev/hda8 ext3 464M 8.1M 432M 2% /tmp
/dev/hda6 ext3 7.4G 1.5G 5.5G 22% /usr
/dev/hda7 ext3 1.9G 96M 1.7G 6% /var
/dev/hdc iso9660 38M 38M 0 100% /mnt/cdrom
total 0
2.6.12-rc1-mm3-GX110
[ 49.198779] EXT3-fs: mounted filesystem with ordered data mode.
[ 56.310394] PCI: Found IRQ 5 for device 0000:01:0c.0
[ 222.804956] rock: directory entry would overflow storage
[ 222.804978] rock: sig=0x5245, size=8, remaining=0
[ 235.551953] rock: directory entry would overflow storage
[ 235.551969] rock: sig=0x5850, size=36, remaining=34
[ 235.551976] rock: directory entry would overflow storage
[ 235.551981] rock: sig=0x5850, size=36, remaining=34
Sorry, I don't have the time to do further troubleshooting, but I
hope this is enough information. The .config for this machine was
http://marc.theaimsgroup.com/?l=linux-kernel&m=111167720523853&w=2
Steven
I found a few more minutes to test two more kernels. The problem
first occured with 2.6.12-rc1-mm2:

2.6.12-rc1 reads the cd-rom OK as reported earlier
2.6.12-rc1-mm1 also reads the cd-rom OK
2.6.12-rc1-mm2 broken same as -mm3 described as above
2.6.12-rc1-mm3 broken as reported earlier

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jason Uhlenkott
2005-03-26 01:46:14 UTC
Permalink
bk-acpi.patch
This doesn't build for SGI sn2:

arch/ia64/kernel/mca.c: In function `ia64_mca_init':
arch/ia64/kernel/mca.c:1394: error: `ACPI_INTERRUPT_CPEI' undeclared (first use in this function)
arch/ia64/kernel/mca.c:1394: error: (Each undeclared identifier is reported only once
arch/ia64/kernel/mca.c:1394: error: for each function it appears in.)
make[1]: *** [arch/ia64/kernel/mca.o] Error 1
make: *** [arch/ia64/kernel] Error 2

This is because we lost CONFIG_ACPI_BOOT -- it now depends on
CONFIG_PM, which we don't have (or want) on sn2. The following fixes
it, but I'm not sure what the original rationale was. Len?

Signed-off-by: Jason Uhlenkott <***@sgi.com>

Index: linux/drivers/acpi/Kconfig
===================================================================
--- linux.orig/drivers/acpi/Kconfig 2005-03-25 12:22:57.909667494 -0800
+++ linux/drivers/acpi/Kconfig 2005-03-25 16:28:35.793588269 -0800
@@ -3,7 +3,6 @@
#

menu "ACPI (Advanced Configuration and Power Interface) Support"
- depends on PM
depends on !X86_VISWS
depends on !IA64_HP_SIM
depends on IA64 || X86
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jason Uhlenkott
2005-03-26 02:05:33 UTC
Permalink
Please send me the .config you'd like to build.
arch/ia64/configs/sn2_defconfig
I believe that what we want to do is include CONFIG_PM.
At first glance, it looks like that will enable suspend/resume
functionality (which I don't think we want on SGI sn2) for a bunch of
drivers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jason Uhlenkott
2005-03-26 03:00:33 UTC
Permalink
What bad things happen if you define CONFIG_PM on SN2?
None, other than slightly enlarging the kernel with some
suspend/resume stuff we don't care about. It's always been
unavailable for SN2 builds:

depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB

but there doesn't appear to be any particular reason for that other
than us not needing it (and in fact SN2 systems can run IA64_GENERIC
kernels with CONFIG_PM enabled without incident).
Re: CONFIG_ACPI_BOOT
I've got a patch that makes it go away -- this looks like
a good reason for me to dust it off... Looks like
arch/ia64/Kconfig defines ACPI and then pulls in drivers/acpi/Kconfig,
which it should not do - it should look like i386/Kconfig...
Sounds good to me. Does that mean everything currently controlled by
CONFIG_ACPI_BOOT will be controlled by CONFIG_ACPI instead?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jesse Barnes
2005-03-26 03:45:33 UTC
Permalink
Post by Jason Uhlenkott
What bad things happen if you define CONFIG_PM on SN2?
None, other than slightly enlarging the kernel with some
suspend/resume stuff we don't care about. It's always been
depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB
but there doesn't appear to be any particular reason for that other
than us not needing it (and in fact SN2 systems can run IA64_GENERIC
kernels with CONFIG_PM enabled without incident).
Re: CONFIG_ACPI_BOOT
I've got a patch that makes it go away -- this looks like
a good reason for me to dust it off... Looks like
arch/ia64/Kconfig defines ACPI and then pulls in drivers/acpi/Kconfig,
which it should not do - it should look like i386/Kconfig...
Yeah, I noticed that too. If you've got a patch to clean it up, we should go
ahead and get it sent off to Tony.

I sent this to linux-ia64 the other day to address these issues.

Jesse
Len Brown
2005-03-26 04:14:38 UTC
Permalink
Post by Jason Uhlenkott
What bad things happen if you define CONFIG_PM on SN2?
None, other than slightly enlarging the kernel with some
suspend/resume stuff we don't care about. It's always been
depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 ||
IA64_HP_ZX1_SWIOTLB
but there doesn't appear to be any particular reason for that other
than us not needing it (and in fact SN2 systems can run IA64_GENERIC
kernels with CONFIG_PM enabled without incident).
good.

I realize now I didn't answer your original question.
The reason ACPI now depends on PM is that
it makes it easier for us to do a more orderly shutdown --
acpi registers as a device so it can do some stuff
upon the PM device shutdowns -- before interrupts are disabled.

I think with all the twisty turney passages
related to the suspend states, poweroff, sys-req, and now kexec,
that it is best if we can keep the code paths as
common as possible or some of them will never get the
testing needed to prevent them from getting broken.

Also, it is now common practice to include PM && ACPI together
in the x86 world. Though technically one could have
ACPI w/o PM and you'd have lost only ACPI_SLEEP, virtually
nobody seems to use/depend-on that combination.

Obviously I hadn't considered SN2 or built its config
before that 1-liner. I'll be sure to build it next time.
Post by Jason Uhlenkott
Re: CONFIG_ACPI_BOOT
I've got a patch that makes it go away -- this looks like
a good reason for me to dust it off... Looks like
arch/ia64/Kconfig defines ACPI and then pulls in
drivers/acpi/Kconfig,
which it should not do - it should look like i386/Kconfig...
Sounds good to me. Does that mean everything currently controlled by
CONFIG_ACPI_BOOT will be controlled by CONFIG_ACPI instead?
yes. this was in -mm a while back, but got pushed onto the back
burner when more pressing things came up.

thanks,
-Len

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jason Uhlenkott
2005-03-26 05:56:35 UTC
Permalink
Post by Len Brown
I realize now I didn't answer your original question.
The reason ACPI now depends on PM is that
it makes it easier for us to do a more orderly shutdown --
acpi registers as a device so it can do some stuff
upon the PM device shutdowns -- before interrupts are disabled.
I think with all the twisty turney passages
related to the suspend states, poweroff, sys-req, and now kexec,
that it is best if we can keep the code paths as
common as possible or some of them will never get the
testing needed to prevent them from getting broken.
Also, it is now common practice to include PM && ACPI together
in the x86 world. Though technically one could have
ACPI w/o PM and you'd have lost only ACPI_SLEEP, virtually
nobody seems to use/depend-on that combination.
OK, that makes sense. I see now that Jesse has already sent a patch
to allow CONFIG_PM on sn2, so we'll be fine as soon as that gets
merged.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Len Brown
2005-03-26 02:31:16 UTC
Permalink
Post by Jason Uhlenkott
Please send me the .config you'd like to build.
arch/ia64/configs/sn2_defconfig
I believe that what we want to do is include CONFIG_PM.
At first glance, it looks like that will enable suspend/resume
functionality (which I don't think we want on SGI sn2) for a bunch of
drivers.
What bad things happen if you define CONFIG_PM on SN2?

Re: CONFIG_ACPI_BOOT
I've got a patch that makes it go away -- this looks like
a good reason for me to dust it off... Looks like
arch/ia64/Kconfig defines ACPI and then pulls in drivers/acpi/Kconfig,
which it should not do - it should look like i386/Kconfig...

-Len

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Len Brown
2005-03-26 01:59:00 UTC
Permalink
Post by Jason Uhlenkott
bk-acpi.patch
arch/ia64/kernel/mca.c:1394: error: `ACPI_INTERRUPT_CPEI' undeclared
(first use in this function)
arch/ia64/kernel/mca.c:1394: error: (Each undeclared identifier is reported only once
arch/ia64/kernel/mca.c:1394: error: for each function it appears in.)
make[1]: *** [arch/ia64/kernel/mca.o] Error 1
make: *** [arch/ia64/kernel] Error 2
This is because we lost CONFIG_ACPI_BOOT -- it now depends on
CONFIG_PM, which we don't have (or want) on sn2. The following fixes
it, but I'm not sure what the original rationale was. Len?
Please send me the .config you'd like to build.
I believe that what we want to do is include CONFIG_PM.
Note also that CONFIG_ACPI_BOOT will be going away --
to be replaced simply by CONFIG_ACPI.

thanks,
-Len

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Paul Blazejowski
2005-03-26 04:25:35 UTC
Permalink
Something funky going on with ACPI on nForce2? NFS is no go either.

Linux version 2.6.12-rc1-mm3 (***@blaze) (gcc version 3.3.4) #2
PREEMPT Fri Mar 25 14:30:56 EST 2005

[snip ...]

ACPI: Subsystem revision 20050309
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] segment is 0
PCI: nForce2 C1 Halt Disconnect fixup
Boot video device is 0000:03:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Can't get handler for 0000:00:00.1
ACPI: Can't get handler for 0000:00:00.2
ACPI: Can't get handler for 0000:00:00.3
ACPI: Can't get handler for 0000:00:00.4
ACPI: Can't get handler for 0000:00:00.5
ACPI: Can't get handler for 0000:01:0a.0
ACPI: Can't get handler for 0000:01:0b.0
ACPI: Can't get handler for 0000:01:0c.0
ACPI: Can't get handler for 0000:03:00.1
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled.
ACPI: PCI Interrupt Link [APC3] (IRQs *18), disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs *19), disabled.
ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs *23), disabled.
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: No ACPI bus support for 00:00
ACPI: No ACPI bus support for 00:01
ACPI: No ACPI bus support for 00:02
ACPI: No ACPI bus support for 00:03
ACPI: No ACPI bus support for 00:04
ACPI: No ACPI bus support for 00:05
ACPI: No ACPI bus support for 00:06
ACPI: No ACPI bus support for 00:07
ACPI: No ACPI bus support for 00:08
ACPI: No ACPI bus support for 00:09
ACPI: No ACPI bus support for 00:0a
ACPI: No ACPI bus support for 00:0b
ACPI: No ACPI bus support for 00:0c
ACPI: No ACPI bus support for 00:0d
pnp: PnP ACPI: found 14 devices
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
pnp: 00:00: ioport range 0x1000-0x107f could not be reserved
pnp: 00:00: ioport range 0x1080-0x10ff has been reserved
pnp: 00:00: ioport range 0x1400-0x147f has been reserved
pnp: 00:00: ioport range 0x1480-0x14ff could not be reserved
pnp: 00:00: ioport range 0x1800-0x187f has been reserved
pnp: 00:00: ioport range 0x1880-0x18ff has been reserved
pnp: 00:01: ioport range 0x1c00-0x1c3f has been reserved
pnp: 00:01: ioport range 0x2000-0x203f has been reserved
ACPI: Power Button (FF) [PWRF]
PNP: PS/2 controller doesn't have AUX irq; using default 0xc
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 112
ACPI: No ACPI bus support for i8042
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ACPI: No ACPI bus support for serial8250
ACPI: No ACPI bus support for serio0
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ACPI: No ACPI bus support for serio1
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

[snip ...]

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ACPI: No ACPI bus support for 0.0
ACPI: No ACPI bus support for 0.1
Probing IDE interface ide1...
hdc: PLEXTOR DVDR PX-716A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
ACPI: No ACPI bus support for 1.0
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
ACPI: PCI Interrupt 0000:01:0a.0[A] -> Link [APC3] -> GSI 18 (level,
high) -> IRQ 18
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec 29160 Ultra160 SCSI adapter>
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

(scsi0:A:4): 20.000MB/s transfers (20.000MHz, offset 16)
(scsi0:A:6): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Vendor: PLEXTOR Model: CD-R PX-W1210S Rev: 1.06
Type: CD-ROM ANSI SCSI revision: 02
ACPI: No ACPI bus support for 0:0:4:0
Vendor: IBM Model: DDYS-T36950N Rev: S80D
Type: Direct-Access ANSI SCSI revision: 03
scsi0:A:6:0: Tagged Queuing enabled. Depth 32
ACPI: No ACPI bus support for 0:0:6:0
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
ACPI: PCI Interrupt 0000:01:0c.0[A] -> Link [APC2] -> GSI 17 (level,
high) -> IRQ 17
Found Controller: IT8212 UDMA/ATA133 RAID Controller
FindDevices: device 0 is IDE
Channel[0] BM-DMA at 0x9800-0x9807
Channel[1] BM-DMA at 0x9808-0x980F
scsi1 : ITE RAIDExpress133
Vendor: ITE Model: IT8212F Rev: 1.45
Type: Direct-Access ANSI SCSI revision: 00
ACPI: No ACPI bus support for 1:0:0:0

[snip ...]

ieee1394: Initialized config rom entry `ip1394'
ohci1394: $Rev: 1250 $ Ben Collins <***@debian.org>
ACPI: PCI Interrupt Link [APCM] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [APCM] -> GSI 22 (level,
high) -> IRQ 22
PCI: Setting latency timer of device 0000:00:0d.0 to 64
ACPI: No ACPI bus support for fw-host0
ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:02.2[C] -> Link [APCL] -> GSI 22 (level,
high) -> IRQ 22
PCI: Setting latency timer of device 0000:00:02.2 to 64
ehci_hcd 0000:00:02.2: nVidia Corporation nForce2 USB Controller
ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.2: irq 22, io mem 0xee083000
PCI: cache line size of 64 is not supported by device 0000:00:02.2
ehci_hcd 0000:00:02.2: park 0
ehci_hcd 0000:00:02.2: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
ACPI: No ACPI bus support for usb1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
ACPI: No ACPI bus support for 1-0:1.0
ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [APCF] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 21 (level,
high) -> IRQ 21
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: nVidia Corporation nForce2 USB Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:02.0: irq 21, io mem 0xee087000
ACPI: No ACPI bus support for usb2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ACPI: No ACPI bus support for 2-0:1.0
ACPI: PCI Interrupt Link [APCG] enabled at IRQ 20
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCG] -> GSI 20 (level,
high) -> IRQ 20
PCI: Setting latency timer of device 0000:00:02.1 to 64
ohci_hcd 0000:00:02.1: nVidia Corporation nForce2 USB Controller (#2)
ACPI: No ACPI bus support for 8a1cc7ffff0020ed
ieee1394: Host added: ID:BUS[0-00:1023] GUID[8a1cc7ffff0020ed]
ACPI: No ACPI bus support for 8a1cc7ffff0020ed-0
e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:02.1: irq 20, io mem 0xee082000
ACPI: No ACPI bus support for usb3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
ACPI: No ACPI bus support for 3-0:1.0
eth1394: $Rev: 1247 $ Ben Collins <***@debian.org>
eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
usb 1-3: new high speed USB device using ehci_hcd and address 3
ACPI: No ACPI bus support for 1-3
hub 1-3:1.0: USB hub found
hub 1-3:1.0: 4 ports detected
ACPI: No ACPI bus support for 1-3:1.0
i2c_adapter i2c-4: nForce2 SMBus adapter at 0x1c00
i2c_adapter i2c-5: nForce2 SMBus adapter at 0x2000
eth1: no link during initialization.
usb 2-1: new low speed USB device using ohci_hcd and address 2
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected NVIDIA nForce2 chipset
agpgart: AGP aperture is 128M @ 0xe0000000
ACPI: No ACPI bus support for 2-1
ACPI: No ACPI bus support for 2-1:1.0
usbcore: registered new driver hiddev

[snip ...]
RPC: failed to contact portmap (errno -512).

mount shows

mount -t nfs blazebox:/home/paul /mnt/hd
mount: blazebox:/home/paul: can't read superblock

And the rpcinfo -p on host blazebox [ running FreeBSD 5.3-STABLE ] shows

program vers proto port
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100000 4 7 111 portmapper
100000 3 7 111 portmapper
100000 2 7 111 portmapper
100005 1 udp 752 mountd
100005 3 udp 752 mountd
100005 1 tcp 666 mountd
100005 3 tcp 666 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100021 0 udp 751 nlockmgr
100021 1 udp 751 nlockmgr
100021 3 udp 751 nlockmgr
100021 4 udp 751 nlockmgr
100021 0 tcp 965 nlockmgr
100021 1 tcp 965 nlockmgr
100021 3 tcp 965 nlockmgr
100021 4 tcp 965 nlockmgr
100024 1 udp 879 status
100024 1 tcp 645 status

Trond has helped me before with debugging NFS
--
FreeBSD the Power to Serve!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jean Delvare
2005-03-26 10:21:56 UTC
Permalink
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/
(...)
bk-alsa.patch
This one made /proc/asound/card0/id change from "Live" to "Unknown" on
one of my systems, preventing alsatcl from properly restoring my mixer
settings.

I guess this wasn't exactly expected?

00:0d.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 06)
Subsystem: Creative Labs CT4832 SBLive! Value
Flags: bus master, medium devsel, latency 48, IRQ 5
I/O ports at 8800 [size=32]

Class: 0401
Device: 1102:0002
Subsystem: 1102:8027

Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Takashi Iwai
2005-03-29 12:30:34 UTC
Permalink
At Sat, 26 Mar 2005 11:19:45 +0100,
Post by Jean Delvare
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/
(...)
bk-alsa.patch
This one made /proc/asound/card0/id change from "Live" to "Unknown" on
one of my systems, preventing alsatcl from properly restoring my mixer
settings.
I guess this wasn't exactly expected?
Hmm, perhaps it's a side effect of chip detection patch by James.
But "Unknown" is bad, of course.

How does /proc/asound/cards look?

Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jean Delvare
2005-03-29 17:58:57 UTC
Permalink
Hi Takashi,
Post by Takashi Iwai
Post by Jean Delvare
This one made /proc/asound/card0/id change from "Live" to "Unknown"
on one of my systems, preventing alsatcl from properly restoring my
mixer settings.
Hmm, perhaps it's a side effect of chip detection patch by James.
But "Unknown" is bad, of course.
How does /proc/asound/cards look?
0 [Unknown ]: EMU10K1 - SB Live [Unknown]
SB Live [Unknown] (rev.6, serial:0x80271102) at 0x8800, irq 5

With the bk-alsa patch reverted, it looks like:

0 [Live ]: EMU10K1 - Sound Blaster Live!
Sound Blaster Live! (rev.6, serial:0x80271102) at 0x8800, irq 5

Hope that helps. If you need any additional information, just ask.

Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Sean Neakums
2005-03-26 19:41:23 UTC
Permalink
On a PowerBook5.4 I get the below when I insert the PCMCIA card or
boot with it inserted; however, if I boot with no card inserted,
sleep-resume and insert the card it works fine. Similar with
2.6.12-rc1-mm1; not sure why I didn't notice until now, since I
happily used it for six days or so, PCMCIA and all, although there was
*some* PCMCIA-related issue I failed to note and cannot now recall.

Yenta: CardBus bridge found at 0001:10:13.0 [0000:0000]
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0001:10:13.0, mfunc 0x00001002, devctl 0x60
Yenta: ISA IRQ mask 0x0000, PCI irq 53
Socket status: 30000010
pcmcia: I/O behind socket: 0x0 - 0x7fffff
pcmcia: Memory behind socket: 0xf3000000 - 0xf3ffffff
pcmcia: Memory behind socket: 0x80000000 - 0xafffffff
cs: memory probe 0x80000000-0xafffffff:Machine check in kernel mode.
Caused by (from SRR1=149030): Transfer error ack signal
Oops: machine check, sig: 7 [#1]
NIP: F20CEC90 LR: F20CEC64 SP: EF8F3BE0 REGS: ef8f3b30 TRAP: 0200 Not tainted
MSR: 00149030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c12966a0[805] 'modprobe' THREAD: ef8f2000
Last syscall: 128
GPR00: 00000060 EF8F3BE0 C12966A0 F103C000 00000000 EF8F9880 00000002 EF8F3C5A
GPR08: C04B6370 F103D000 00000000 00001000 22002488 1001E284 10017070 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 C1225D40 30000000 00000000
GPR24: EF8F3C5A 00000021 00000002 C12D282C 00000000 00000000 00000002 EF8F3C5A
NIP [f20cec90] pcmcia_read_cis_mem+0x184/0x1c0 [pcmcia_core]
LR [f20cec64] pcmcia_read_cis_mem+0x158/0x1c0 [pcmcia_core]
Call trace:
[f20cefa0] read_cis_cache+0x144/0x168 [pcmcia_core]
[f20cf668] pccard_get_next_tuple+0x7c/0x2a8 [pcmcia_core]
[f20cf378] pccard_get_first_tuple+0x94/0x144 [pcmcia_core]
[f20d0fb8] pccard_validate_cis+0x94/0x27c [pcmcia_core]
[f106e3c8] readable+0x88/0xa8 [rsrc_nonstatic]
[f106e5a0] cis_readable+0xc8/0xe4 [rsrc_nonstatic]
[f106e860] do_mem_probe+0x1d0/0x1e8 [rsrc_nonstatic]
[f106e8b8] validate_mem+0x40/0x68 [rsrc_nonstatic]
[f106e99c] pcmcia_nonstatic_validate_mem+0xbc/0xc8 [rsrc_nonstatic]
[f20d134c] pcmcia_validate_mem+0x34/0x38 [pcmcia_core]
[f20e39b4] pcmcia_card_add+0x28/0xc0 [pcmcia]
[f20e441c] ds_event+0x8c/0xe4 [pcmcia]
[f20cda3c] send_event+0x70/0xc8 [pcmcia_core]
[f20ce52c] pccard_register_pcmcia+0xac/0xcc [pcmcia_core]
[f20e49b4] pcmcia_bus_add_socket+0xa8/0x104 [pcmcia]
--
Dag vijandelijk luchtschip de huismeester is dood
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Dominik Brodowski
2005-03-26 22:03:05 UTC
Permalink
Post by Sean Neakums
On a PowerBook5.4 I get the below when I insert the PCMCIA card or
boot with it inserted; however, if I boot with no card inserted,
sleep-resume and insert the card it works fine. Similar with
2.6.12-rc1-mm1; not sure why I didn't notice until now, since I
happily used it for six days or so, PCMCIA and all, although there was
*some* PCMCIA-related issue I failed to note and cannot now recall.
If you revert the patch named
pcmcia-mark-parent-bridge-windows-as-resources-available-for-pcmcia-devices.patch
the oops should disappear. However, I had no chance yet to fully debug
what's going on here. So I'd prefer it if you first applied the attached test
patch and sent me (off-list) the dmesg output. Also, it is very strange that
it doesn't trigger if you did a sleep-resume cycle before... Ben, any idea?

Dominik
Russell King
2005-03-28 11:06:40 UTC
Permalink
Unable to handle kernel paging request at virtual address f3a6ce68
c0244109
*pde = 00000000
Oops: 0000 [#1]
SMP DEBUG_PAGEALLOC
Modules linked in: hidp hci_usb sermouse nfsd exportfs md5 ipv6 lp
autofs4 eeprom lm85 i2c_sensor rfcomm l2cap bluetooth nfs lock
d sunrpc usb_storage pwc videodev dm_mod video button battery ac
ohci1394 ieee1394 uhci_hcd ehci_hcd parport_serial parport_pc parp
ort hw_random i2c_i801 i2c_core emu10k1_gp gameport e100 mii floppy ext3
jbd ata_piix libata sd_mod scsi_mod
CPU: 0
EIP: 0060:[<c0244109>] Not tainted VLI
EFLAGS: 00010286 (2.6.12-rc1-mm3)
EIP is at serport_ldisc_write_wakeup+0x9/0x20
eax: f3a6cdf8 ebx: f73d7000 ecx: c038e374 edx: c0244100
esi: f73d700c edi: f73d7000 ebp: c049e900 esp: f7568dc0
ds: 007b es: 007b ss: 0068
Process inputattach (pid: 2932, threadinfo=f7568000 task=f6993ac0)
Stack: c021bb08 00000286 f6c31000 c0245e4a f6c31018 f73d7000 f67c1e88
cbff5c
00000000 c021ceaa 00000000 00000000 00000000 c1e46000 c1e46000
00000000
00000000 c011b739 00000046 c1e46000 00000001 f2c00000 f2c00000
c011b8b4
^M [<c021bb08>] tty_wakeup+0x48/0x70
^M [<c0245e4a>] uart_close+0xca/0x1e0
Looks like something in the input layer went bang. The code in
serport_ldisc_write_wakeup is:

0: 8b 80 a8 09 00 00 mov 0x9a8(%eax),%eax
6: 8b 40 14 mov 0x14(%eax),%eax
9: 8b 50 70 mov 0x70(%eax),%edx <====
c: 85 d2 test %edx,%edx
e: 74 09 je 0x19

and the marked line exploded on you. The above instructions correspond
with:

0: struct serport *sp = (struct serport *) tty->disc_data;
6: serio_drv_write_wakeup(sp->serio);
9: if (serio->drv

So, "serio" was this strange 0xf3a6cdf8 value. But why? One for the
input people I think.
^M [<c021ceaa>] release_dev+0x14a/0x750
^M [<c011b739>] change_page_attr+0x29/0x60
^M [<c011b8b4>] kernel_map_pages+0x84/0xa0
^M [<c014cbca>] store_stackinfo+0x5a/0x90
^M [<c01664c8>] __fput+0x108/0x180
^M [<c018b59b>] inotify_inode_queue_event+0x2b/0x40
^M [<c021d97f>] tty_release+0xf/0x20
^M [<c016644a>] __fput+0x8a/0x180
^M [<c0164d7b>] filp_close+0x4b/0x70
^M [<c0125254>] put_files_struct+0x74/0x100
^M [<c012610c>] do_exit+0x11c/0x420
^M [<c012647d>] do_group_exit+0x2d/0xa0
^M [<c012f74c>] get_signal_to_deliver+0x20c/0x310
^M [<c0103deb>] do_signal+0x5b/0x140
^M [<c011ea89>] __wake_up+0x29/0x40
^M [<c021b60c>] tty_ldisc_deref+0x3c/0x70
^M [<c021c267>] tty_read+0xc7/0x130
^M [<c0243fb0>] serport_ldisc_read+0x0/0x100
^M [<c016ecd3>] sys_fstat64+0x23/0x30
^M [<c021c1a0>] tty_read+0x0/0x130
^M [<c0165547>] vfs_read+0x97/0x140
^M [<c016585c>] sys_read+0x3c/0x70
^M [<c0103efa>] do_notify_resume+0x2a/0x40
^M [<c01040be>] work_notifysig+0x13/0x25
^MCode: e8 0f b6 c5 88 4b 4b 31 d2 c1 e9 10 88 43 4a 88 4b 49 89 d0 5b
c3 8d b6 00 00 00 00 8d bf 00 00 00 00 8b 80 a8 09 00 00 8b
40 14 <8b> 50 70 85 d2 74 09 8b 52 10 85 d2 74 02 ff d2 c3 90 90 90 90
^M [<c0126386>] do_exit+0x396/0x420
^M [<c01059f6>] die+0x166/0x170
^M [<c011a7a3>] do_page_fault+0x1f3/0x6a1
^M [<c0244109>] serport_ldisc_write_wakeup+0x9/0x20
^M [<c011b36c>] __change_page_attr+0x4c/0x3f0
^M [<c011a5b0>] do_page_fault+0x0/0x6a1
^M [<c010522f>] error_code+0x4f/0x60
^M [<c0244100>] serport_ldisc_write_wakeup+0x0/0x20
^M [<c0244109>] serport_ldisc_write_wakeup+0x9/0x20
^M [<c021bb08>] tty_wakeup+0x48/0x70
^M [<c0245e4a>] uart_close+0xca/0x1e0
^M [<c021ceaa>] release_dev+0x14a/0x750
^M [<c011b739>] change_page_attr+0x29/0x60
^M [<c011b8b4>] kernel_map_pages+0x84/0xa0
^M [<c014cbca>] store_stackinfo+0x5a/0x90
^M [<c01664c8>] __fput+0x108/0x180
^M [<c018b59b>] inotify_inode_queue_event+0x2b/0x40
^M [<c021d97f>] tty_release+0xf/0x20
^M [<c016644a>] __fput+0x8a/0x180
^M [<c0164d7b>] filp_close+0x4b/0x70
^M [<c0125254>] put_files_struct+0x74/0x100
^M [<c012610c>] do_exit+0x11c/0x420
^M [<c012647d>] do_group_exit+0x2d/0xa0
^M [<c012f74c>] get_signal_to_deliver+0x20c/0x310
^M [<c0103deb>] do_signal+0x5b/0x140
^M [<c011ea89>] __wake_up+0x29/0x40
^M [<c021b60c>] tty_ldisc_deref+0x3c/0x70
^M [<c021c267>] tty_read+0xc7/0x130
^M [<c0243fb0>] serport_ldisc_read+0x0/0x100
^M [<c016ecd3>] sys_fstat64+0x23/0x30
^M [<c021c1a0>] tty_read+0x0/0x130
^M [<c0165547>] vfs_read+0x97/0x140
^M [<c016585c>] sys_read+0x3c/0x70
^M [<c0103efa>] do_notify_resume+0x2a/0x40
^M [<c01040be>] work_notifysig+0x13/0x25
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Reuben Farrelly
2005-03-28 10:32:23 UTC
Permalink
Hi,
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/
- Mainly a bunch of fixes relative to 2.6.12-rc1-mm2.
- Again, we'd like people who have had recent DRM and USB resume problems to
test and report, please.
- The bk-ide-dev tree is back after a couple of weeks of difficulties.
- Jeff asks that anyone who has had problems with the Silicon Image SATA
drivers test sata_sil-corruption--lockup-fix.patch, which is included in
this kernel.
I'm repeatably getting this crash on shutdown in -mm3, and a few
releases earlier (but I can't be certain it was the same crash..)

Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS4 at I/O 0xa400 (irq = 16) is a 16550A
ttyS5 at I/O 0xa408 (irq = 16) is a 16550A

This _may_ be the culprit, but I'm not sure:

03:03.0 Serial controller: Timedia Technology Co Ltd PCI2S550 (Dual
16550 UART) (rev 01) (prog-if 02 [16550])
Subsystem: Timedia Technology Co Ltd: Unknown device 0002
Flags: stepping, medium devsel, IRQ 16
I/O ports at a400 [size=32]

The board is an Intel D925XCV.

Shutdown goes like this: (yes, hyperterminal sucks for the ^M
characters, sorry)

INIT: Switching^MINIT: Sending processes the TERM signal
Stopping yum: Disabling nightly yum update: [ OK ]
[ OK ]
Stopping cups-config-daemon: [ OK ]
Stopping HAL daemon: [ OK ]
Stopping system message bus: [ OK ]
Stopping atd: [ OK ]
Stopping cups: [ OK ]
Shutting down xfs: [ OK ]
Shutting down console mouse services: [ OK ]
Unable to handle kernel paging request at virtual address f3a6ce68
printing eip:
c0244109
*pde = 00000000
Oops: 0000 [#1]
SMP DEBUG_PAGEALLOC
Modules linked in: hidp hci_usb sermouse nfsd exportfs md5 ipv6 lp
autofs4 eeprom lm85 i2c_sensor rfcomm l2cap bluetooth nfs lock
d sunrpc usb_storage pwc videodev dm_mod video button battery ac
ohci1394 ieee1394 uhci_hcd ehci_hcd parport_serial parport_pc parp
ort hw_random i2c_i801 i2c_core emu10k1_gp gameport e100 mii floppy ext3
jbd ata_piix libata sd_mod scsi_mod
CPU: 0
EIP: 0060:[<c0244109>] Not tainted VLI
EFLAGS: 00010286 (2.6.12-rc1-mm3)
EIP is at serport_ldisc_write_wakeup+0x9/0x20
eax: f3a6cdf8 ebx: f73d7000 ecx: c038e374 edx: c0244100
esi: f73d700c edi: f73d7000 ebp: c049e900 esp: f7568dc0
ds: 007b es: 007b ss: 0068
Process inputattach (pid: 2932, threadinfo=f7568000 task=f6993ac0)
Stack: c021bb08 00000286 f6c31000 c0245e4a f6c31018 f73d7000 f67c1e88
cbff5c
00000000 c021ceaa 00000000 00000000 00000000 c1e46000 c1e46000
00000000
00000000 c011b739 00000046 c1e46000 00000001 f2c00000 f2c00000
c011b8b4
Call Trace:
^M [<c021bb08>] tty_wakeup+0x48/0x70
^M [<c0245e4a>] uart_close+0xca/0x1e0
^M [<c021ceaa>] release_dev+0x14a/0x750
^M [<c011b739>] change_page_attr+0x29/0x60
^M [<c011b8b4>] kernel_map_pages+0x84/0xa0
^M [<c014cbca>] store_stackinfo+0x5a/0x90
^M [<c01664c8>] __fput+0x108/0x180
^M [<c018b59b>] inotify_inode_queue_event+0x2b/0x40
^M [<c021d97f>] tty_release+0xf/0x20
^M [<c016644a>] __fput+0x8a/0x180
^M [<c0164d7b>] filp_close+0x4b/0x70
^M [<c0125254>] put_files_struct+0x74/0x100
^M [<c012610c>] do_exit+0x11c/0x420
^M [<c012647d>] do_group_exit+0x2d/0xa0
^M [<c012f74c>] get_signal_to_deliver+0x20c/0x310
^M [<c0103deb>] do_signal+0x5b/0x140
^M [<c011ea89>] __wake_up+0x29/0x40
^M [<c021b60c>] tty_ldisc_deref+0x3c/0x70
^M [<c021c267>] tty_read+0xc7/0x130
^M [<c0243fb0>] serport_ldisc_read+0x0/0x100
^M [<c016ecd3>] sys_fstat64+0x23/0x30
^M [<c021c1a0>] tty_read+0x0/0x130
^M [<c0165547>] vfs_read+0x97/0x140
^M [<c016585c>] sys_read+0x3c/0x70
^M [<c0103efa>] do_notify_resume+0x2a/0x40
^M [<c01040be>] work_notifysig+0x13/0x25
^MCode: e8 0f b6 c5 88 4b 4b 31 d2 c1 e9 10 88 43 4a 88 4b 49 89 d0 5b
c3 8d b6 00 00 00 00 8d bf 00 00 00 00 8b 80 a8 09 00 00 8b
40 14 <8b> 50 70 85 d2 74 09 8b 52 10 85 d2 74 02 ff d2 c3 90 90 90 90
^M BUG: atomic counter underflow at:
^M [<c0126386>] do_exit+0x396/0x420
^M [<c01059f6>] die+0x166/0x170
^M [<c011a7a3>] do_page_fault+0x1f3/0x6a1
^M [<c0244109>] serport_ldisc_write_wakeup+0x9/0x20
^M [<c011b36c>] __change_page_attr+0x4c/0x3f0
^M [<c011a5b0>] do_page_fault+0x0/0x6a1
^M [<c010522f>] error_code+0x4f/0x60
^M [<c0244100>] serport_ldisc_write_wakeup+0x0/0x20
^M [<c0244109>] serport_ldisc_write_wakeup+0x9/0x20
^M [<c021bb08>] tty_wakeup+0x48/0x70
^M [<c0245e4a>] uart_close+0xca/0x1e0
^M [<c021ceaa>] release_dev+0x14a/0x750
^M [<c011b739>] change_page_attr+0x29/0x60
^M [<c011b8b4>] kernel_map_pages+0x84/0xa0
^M [<c014cbca>] store_stackinfo+0x5a/0x90
^M [<c01664c8>] __fput+0x108/0x180
^M [<c018b59b>] inotify_inode_queue_event+0x2b/0x40
^M [<c021d97f>] tty_release+0xf/0x20
^M [<c016644a>] __fput+0x8a/0x180
^M [<c0164d7b>] filp_close+0x4b/0x70
^M [<c0125254>] put_files_struct+0x74/0x100
^M [<c012610c>] do_exit+0x11c/0x420
^M [<c012647d>] do_group_exit+0x2d/0xa0
^M [<c012f74c>] get_signal_to_deliver+0x20c/0x310
^M [<c0103deb>] do_signal+0x5b/0x140
^M [<c011ea89>] __wake_up+0x29/0x40
^M [<c021b60c>] tty_ldisc_deref+0x3c/0x70
^M [<c021c267>] tty_read+0xc7/0x130
^M [<c0243fb0>] serport_ldisc_read+0x0/0x100
^M [<c016ecd3>] sys_fstat64+0x23/0x30
^M [<c021c1a0>] tty_read+0x0/0x130
^M [<c0165547>] vfs_read+0x97/0x140
^M [<c016585c>] sys_read+0x3c/0x70
^M [<c0103efa>] do_notify_resume+0x2a/0x40
^M [<c01040be>] work_notifysig+0x13/0x25
^MUnable to handle kernel NULL pointer dereference at virtual address
00000020
^M printing eip:
^Mc0121320
^M*pde = 0041f001
^MOops: 0000 [#2]
^MSMP DEBUG_PAGEALLOC

(there's a bit more, which I can put up online if it's helpful)

Reuben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Dmitry Torokhov
2005-03-29 06:36:35 UTC
Permalink
Post by Reuben Farrelly
Hi,
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/
- Mainly a bunch of fixes relative to 2.6.12-rc1-mm2.
- Again, we'd like people who have had recent DRM and USB resume problems to
test and report, please.
- The bk-ide-dev tree is back after a couple of weeks of difficulties.
- Jeff asks that anyone who has had problems with the Silicon Image SATA
drivers test sata_sil-corruption--lockup-fix.patch, which is included in
this kernel.
I'm repeatably getting this crash on shutdown in -mm3, and a few
releases earlier (but I can't be certain it was the same crash..)
It would be nice to know when it started breaking... At least point release,
not -rc or -bk.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Reuben Farrelly
2005-03-28 11:06:39 UTC
Permalink
Post by Reuben Farrelly
I'm repeatably getting this crash on shutdown in -mm3, and a few
releases earlier (but I can't be certain it was the same crash..)
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS4 at I/O 0xa400 (irq = 16) is a 16550A
ttyS5 at I/O 0xa408 (irq = 16) is a 16550A
03:03.0 Serial controller: Timedia Technology Co Ltd PCI2S550 (Dual
16550 UART) (rev 01) (prog-if 02 [16550])
Subsystem: Timedia Technology Co Ltd: Unknown device 0002
Flags: stepping, medium devsel, IRQ 16
I/O ports at a400 [size=32]
Ugh. I'm an idiot, that will teach me for having two sessions to boxes
running at once.

Wrong info above, but the trace is still valid.

Correct info follows:

ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS14 at I/O 0xb400 (irq = 217) is a 16550A
ttyS15 at I/O 0xb000 (irq = 217) is a 16550A

06:02.0 Serial controller: NetMos Technology PCI 9835 Multi-I/O
Controller (rev
01) (prog-if 02 [16550])
Subsystem: LSI Logic / Symbios Logic 2S (16C550 UART)
Flags: medium devsel, IRQ 217
I/O ports at b400 [size=8]
I/O ports at b000 [size=8]
I/O ports at ac00 [size=8]
I/O ports at a800 [size=8]
I/O ports at a400 [size=8]
I/O ports at a000 [size=16]
Post by Reuben Farrelly
The board is an Intel D925XCV.
Shutdown goes like this: (yes, hyperterminal sucks for the ^M
characters, sorry)
<trace omitted>

reuben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Loading...