* Re: 2.6.12-mm2
2005-06-26 11:03 2.6.12-mm2 Andrew Morton
@ 2005-06-26 11:42 ` Russell King
2005-06-26 23:17 ` 2.6.12-mm2 Grant Coady
2005-06-26 12:04 ` 2.6.12-mm2 Michał Piotrowski
` (7 subsequent siblings)
8 siblings, 1 reply; 57+ messages in thread
From: Russell King @ 2005-06-26 11:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sun, Jun 26, 2005 at 04:03:29AM -0700, Andrew Morton wrote:
> - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
> the recent PCI breakage sorted out.
I'm not sure what PCI breakage you're referring to, but a lot of the
Cardbus-centric "breakage" isn't a regression - it's new machines
with weird PCI BIOS setups being incompatible Linux's current PCI
bus handing strategy.
I've been trying to get this fixed for a considerable time, but linux-pci
folk seem to be disinterested.
The assumption that the PCI BIOS will sanely assign the PCI bus numbers
and that Linux does not need to reassign them is looking increasingly
incorrect - most of the Cardbus "why can't the system see my card"
are resolved by passing "pci=assign-busses", which causes the PCI
subsystem to renumber all PCI busses.
So far, no one who has tried this solution has reported any additional
problems that I'm aware of.
Therefore, maybe that should become the default behaviour?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: 2.6.12-mm2
2005-06-26 11:42 ` 2.6.12-mm2 Russell King
@ 2005-06-26 23:17 ` Grant Coady
2005-06-27 8:11 ` 2.6.12-mm2 Russell King
0 siblings, 1 reply; 57+ messages in thread
From: Grant Coady @ 2005-06-26 23:17 UTC (permalink / raw)
To: Russell King; +Cc: Andrew Morton, linux-kernel
On Sun, 26 Jun 2005 12:42:19 +0100, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>On Sun, Jun 26, 2005 at 04:03:29AM -0700, Andrew Morton wrote:
>> - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
>> the recent PCI breakage sorted out.
>
>I'm not sure what PCI breakage you're referring to, but a lot of the
>Cardbus-centric "breakage" isn't a regression - it's new machines
>with weird PCI BIOS setups being incompatible Linux's current PCI
>bus handing strategy.
>
>I've been trying to get this fixed for a considerable time, but linux-pci
>folk seem to be disinterested.
>
>The assumption that the PCI BIOS will sanely assign the PCI bus numbers
>and that Linux does not need to reassign them is looking increasingly
>incorrect - most of the Cardbus "why can't the system see my card"
>are resolved by passing "pci=assign-busses", which causes the PCI
>subsystem to renumber all PCI busses.
Not the case for where I'm having problems, Toshiba laptop, more
info on http://scatter.mine.nu/test/linux-2.6/tosh/
--- ioports-2.6.12.1a 2005-06-27 09:00:21.000000000 +1000
+++ ioports-2.6.12-mm2a 2005-06-27 09:03:44.000000000 +1000
@@ -10,20 +10,13 @@
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
-02f8-02ff : 0000:00:07.0
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vesafb
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
-1c00-1cff : 0000:00:07.0
-4000-40ff : PCI CardBus #02
- 4000-407f : 0000:02:00.0
- 4000-407f : xircom_cb
-4400-44ff : PCI CardBus #02
-fc00-fcff : 0000:00:0c.0
- fc00-fcff : ESS Maestro
+fc00-fcff : ESS Maestro
fd00-fd3f : motherboard
fe00-fe3f : 0000:00:05.3
fe00-fe3f : motherboard
@@ -40,8 +33,6 @@
fe90-fe97 : motherboard
fe9e-fe9e : motherboard
feac-feac : motherboard
-ff80-ff9f : 0000:00:05.2
- ff80-ff9f : uhci_hcd
-fff0-ffff : 0000:00:05.1
- fff0-fff7 : ide0
- fff8-ffff : ide1
+ff80-ff9f : uhci_hcd
+fff0-fff7 : ide0
+fff8-ffff : ide1
lilo.conf:
image = /boot/bzImage-2.6.12-mm2a
optional
label = 2.6.12-mm2ap
append="pci=assign-busses"
--- ioports-2.6.12.1a 2005-06-27 09:00:21.000000000 +1000
+++ ioports-2.6.12-mm2ap 2005-06-27 09:06:31.000000000 +1000
@@ -10,20 +10,13 @@
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
-02f8-02ff : 0000:00:07.0
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vesafb
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
-1c00-1cff : 0000:00:07.0
-4000-40ff : PCI CardBus #02
- 4000-407f : 0000:02:00.0
- 4000-407f : xircom_cb
-4400-44ff : PCI CardBus #02
-fc00-fcff : 0000:00:0c.0
- fc00-fcff : ESS Maestro
+fc00-fcff : ESS Maestro
fd00-fd3f : motherboard
fe00-fe3f : 0000:00:05.3
fe00-fe3f : motherboard
@@ -40,8 +33,6 @@
fe90-fe97 : motherboard
fe9e-fe9e : motherboard
feac-feac : motherboard
-ff80-ff9f : 0000:00:05.2
- ff80-ff9f : uhci_hcd
-fff0-ffff : 0000:00:05.1
- fff0-fff7 : ide0
- fff8-ffff : ide1
+ff80-ff9f : uhci_hcd
+fff0-fff7 : ide0
+fff8-ffff : ide1
--Grant.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: 2.6.12-mm2
2005-06-26 23:17 ` 2.6.12-mm2 Grant Coady
@ 2005-06-27 8:11 ` Russell King
0 siblings, 0 replies; 57+ messages in thread
From: Russell King @ 2005-06-27 8:11 UTC (permalink / raw)
To: Grant Coady; +Cc: Andrew Morton, linux-kernel
On Mon, Jun 27, 2005 at 09:17:34AM +1000, Grant Coady wrote:
> Not the case for where I'm having problems, Toshiba laptop, more
> info on http://scatter.mine.nu/test/linux-2.6/tosh/
Yes in this case. The PCI resources are the ones which say either
PCI CardBus, PCI Bus, or are of the format: xxxx:xx:xx.x, and all
of them are missing.
The ESS Maestro and others which were below these are driver
resources created by the drivers themselves, not the PCI subsystem.
Hence these still show up.
> --- ioports-2.6.12.1a 2005-06-27 09:00:21.000000000 +1000
> +++ ioports-2.6.12-mm2a 2005-06-27 09:03:44.000000000 +1000
> @@ -10,20 +10,13 @@
> 00f0-00ff : fpu
> 0170-0177 : ide1
> 01f0-01f7 : ide0
> -02f8-02ff : 0000:00:07.0
> 0376-0376 : ide1
> 0378-037a : parport0
> 03c0-03df : vesafb
> 03f6-03f6 : ide0
> 03f8-03ff : serial
> 0cf8-0cff : PCI conf1
> -1c00-1cff : 0000:00:07.0
> -4000-40ff : PCI CardBus #02
> - 4000-407f : 0000:02:00.0
> - 4000-407f : xircom_cb
> -4400-44ff : PCI CardBus #02
> -fc00-fcff : 0000:00:0c.0
> - fc00-fcff : ESS Maestro
> +fc00-fcff : ESS Maestro
> fd00-fd3f : motherboard
> fe00-fe3f : 0000:00:05.3
> fe00-fe3f : motherboard
> @@ -40,8 +33,6 @@
> fe90-fe97 : motherboard
> fe9e-fe9e : motherboard
> feac-feac : motherboard
> -ff80-ff9f : 0000:00:05.2
> - ff80-ff9f : uhci_hcd
> -fff0-ffff : 0000:00:05.1
> - fff0-fff7 : ide0
> - fff8-ffff : ide1
> +ff80-ff9f : uhci_hcd
> +fff0-fff7 : ide0
> +fff8-ffff : ide1
>
> lilo.conf:
> image = /boot/bzImage-2.6.12-mm2a
> optional
> label = 2.6.12-mm2ap
> append="pci=assign-busses"
>
> --- ioports-2.6.12.1a 2005-06-27 09:00:21.000000000 +1000
> +++ ioports-2.6.12-mm2ap 2005-06-27 09:06:31.000000000 +1000
> @@ -10,20 +10,13 @@
> 00f0-00ff : fpu
> 0170-0177 : ide1
> 01f0-01f7 : ide0
> -02f8-02ff : 0000:00:07.0
> 0376-0376 : ide1
> 0378-037a : parport0
> 03c0-03df : vesafb
> 03f6-03f6 : ide0
> 03f8-03ff : serial
> 0cf8-0cff : PCI conf1
> -1c00-1cff : 0000:00:07.0
> -4000-40ff : PCI CardBus #02
> - 4000-407f : 0000:02:00.0
> - 4000-407f : xircom_cb
> -4400-44ff : PCI CardBus #02
> -fc00-fcff : 0000:00:0c.0
> - fc00-fcff : ESS Maestro
> +fc00-fcff : ESS Maestro
> fd00-fd3f : motherboard
> fe00-fe3f : 0000:00:05.3
> fe00-fe3f : motherboard
> @@ -40,8 +33,6 @@
> fe90-fe97 : motherboard
> fe9e-fe9e : motherboard
> feac-feac : motherboard
> -ff80-ff9f : 0000:00:05.2
> - ff80-ff9f : uhci_hcd
> -fff0-ffff : 0000:00:05.1
> - fff0-fff7 : ide0
> - fff8-ffff : ide1
> +ff80-ff9f : uhci_hcd
> +fff0-fff7 : ide0
> +fff8-ffff : ide1
>
> --Grant.
>
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: 2.6.12-mm2
2005-06-26 11:03 2.6.12-mm2 Andrew Morton
2005-06-26 11:42 ` 2.6.12-mm2 Russell King
@ 2005-06-26 12:04 ` Michał Piotrowski
2005-06-26 14:04 ` ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees Dominik Brodowski
` (6 subsequent siblings)
8 siblings, 0 replies; 57+ messages in thread
From: Michał Piotrowski @ 2005-06-26 12:04 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
Hi Andrew,
Can you merge OOPS Reporting Tool
(http://stud.wsi.edu.pl/~piotrowskim/files/ort/beta/ort-b3.tar.bz2)
with next -mm release?
Regards,
Michał Piotrowski
^ permalink raw reply [flat|nested] 57+ messages in thread* ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees
2005-06-26 11:03 2.6.12-mm2 Andrew Morton
2005-06-26 11:42 ` 2.6.12-mm2 Russell King
2005-06-26 12:04 ` 2.6.12-mm2 Michał Piotrowski
@ 2005-06-26 14:04 ` Dominik Brodowski
2005-06-26 19:17 ` Andrew Morton
2005-06-27 1:38 ` Grant Coady
2005-06-26 14:18 ` 2.6.12-mm2 Adam Kropelin
` (5 subsequent siblings)
8 siblings, 2 replies; 57+ messages in thread
From: Dominik Brodowski @ 2005-06-26 14:04 UTC (permalink / raw)
To: Andrew Morton, greg, rajesh.shah; +Cc: linux-kernel
On Sun, Jun 26, 2005 at 04:03:29AM -0700, Andrew Morton wrote:
> - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
> the recent PCI breakage sorted out.
pci-yenta-cardbus-fix.patch and the following patch should solve the
initialization time trouble. However, the ACPI-based PCI resource handling
is badly broken, IMHO:
- many resources of devices don't show up in the resource trees (
/proc/iomem and /proc/ioports) any longer. This means that PCMCIA, but
also possibly other subsystems (ISA, PnP, ...) do not know which resources
it cannot use.
- verify_root_windows() should fail if there are no iomem _or_ ioport
resources, not only if there are no iomem _and_ ioport resources.
Nonetheless, with the init-time trouble (hopefully) solved, I'd say that it
is time for the PCMCIA patches to get into mainline.
Dominik
Don't auto-configure yenta sockets for PCMCIA devices if it is connected to
the root PCI bus on the x86 or x86_64 architectures. Previously, this was
handled by the "ioport_resource"/"iomem_resource" check a few lines below,
but with the new ACPI-based resource handling this doesn't catch all cases
any longer.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
--- 2.6.12-mm2/drivers/pcmcia/rsrc_nonstatic.c.orig 2005-06-26 15:04:57.000000000 +0200
+++ 2.6.12-mm2/drivers/pcmcia/rsrc_nonstatic.c 2005-06-26 15:09:02.000000000 +0200
@@ -779,6 +779,17 @@
if (!s->cb_dev || !s->cb_dev->bus)
return -ENODEV;
+#if defined(CONFIG_X86) || defined(CONFIG_X86_64)
+ /* If this is the root bus, the risk of hitting
+ * some strange system devices which aren't protected
+ * by either ACPI resource tables or properly requested
+ * resources is too big. Therefore, don't do auto-adding
+ * of resources at the moment.
+ */
+ if (s->cb_dev->bus->number == 0)
+ return -EINVAL;
+#endif
+
for (i=0; i < PCI_BUS_NUM_RESOURCES; i++) {
res = s->cb_dev->bus->resource[i];
if (!res)
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees
2005-06-26 14:04 ` ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees Dominik Brodowski
@ 2005-06-26 19:17 ` Andrew Morton
2005-06-26 19:34 ` Russell King
2005-06-26 20:14 ` Dominik Brodowski
2005-06-27 1:38 ` Grant Coady
1 sibling, 2 replies; 57+ messages in thread
From: Andrew Morton @ 2005-06-26 19:17 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: greg, rajesh.shah, linux-kernel
Dominik Brodowski <linux@dominikbrodowski.net> wrote:
>
> On Sun, Jun 26, 2005 at 04:03:29AM -0700, Andrew Morton wrote:
> > - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
> > the recent PCI breakage sorted out.
>
> pci-yenta-cardbus-fix.patch and the following patch should solve the
> initialization time trouble. However, the ACPI-based PCI resource handling
> is badly broken, IMHO:
>
> - many resources of devices don't show up in the resource trees (
> /proc/iomem and /proc/ioports) any longer. This means that PCMCIA, but
> also possibly other subsystems (ISA, PnP, ...) do not know which resources
> it cannot use.
Is this a recent regression? Is it only in -mm?
IOW: can you identify the bad patch? Or the bad patcher ;)
> - verify_root_windows() should fail if there are no iomem _or_ ioport
> resources, not only if there are no iomem _and_ ioport resources.
This too.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees
2005-06-26 19:17 ` Andrew Morton
@ 2005-06-26 19:34 ` Russell King
2005-06-26 20:14 ` Dominik Brodowski
1 sibling, 0 replies; 57+ messages in thread
From: Russell King @ 2005-06-26 19:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: Dominik Brodowski, greg, rajesh.shah, linux-kernel
On Sun, Jun 26, 2005 at 12:17:10PM -0700, Andrew Morton wrote:
> Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> >
> > On Sun, Jun 26, 2005 at 04:03:29AM -0700, Andrew Morton wrote:
> > > - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
> > > the recent PCI breakage sorted out.
> >
> > pci-yenta-cardbus-fix.patch and the following patch should solve the
> > initialization time trouble. However, the ACPI-based PCI resource handling
> > is badly broken, IMHO:
> >
> > - many resources of devices don't show up in the resource trees (
> > /proc/iomem and /proc/ioports) any longer. This means that PCMCIA, but
> > also possibly other subsystems (ISA, PnP, ...) do not know which resources
> > it cannot use.
>
> Is this a recent regression? Is it only in -mm?
>
> IOW: can you identify the bad patch? Or the bad patcher ;)
It's greg's pci-somethingortheotheraboutacpi-collection-02 patch (sorry
don't remember it exactly).
It's basically replacing the PCI bus root resources with new resources.
These aren't then attached to the resource tree. However, PCI will
attach the child resources to the (unattached) bus resources.
Hence, all PCI resources remain invisible.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees
2005-06-26 19:17 ` Andrew Morton
2005-06-26 19:34 ` Russell King
@ 2005-06-26 20:14 ` Dominik Brodowski
2005-06-27 20:18 ` Rajesh Shah
1 sibling, 1 reply; 57+ messages in thread
From: Dominik Brodowski @ 2005-06-26 20:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: greg, rajesh.shah, linux-kernel
On Sun, Jun 26, 2005 at 12:17:10PM -0700, Andrew Morton wrote:
> Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> >
> > On Sun, Jun 26, 2005 at 04:03:29AM -0700, Andrew Morton wrote:
> > > - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
> > > the recent PCI breakage sorted out.
> >
> > pci-yenta-cardbus-fix.patch and the following patch should solve the
> > initialization time trouble. However, the ACPI-based PCI resource handling
> > is badly broken, IMHO:
> >
> > - many resources of devices don't show up in the resource trees (
> > /proc/iomem and /proc/ioports) any longer. This means that PCMCIA, but
> > also possibly other subsystems (ISA, PnP, ...) do not know which resources
> > it cannot use.
>
> Is this a recent regression? Is it only in -mm?
Yes. Yes.
> IOW: can you identify the bad patch? Or the bad patcher ;)
gregkh-pci-pci-collect-host-bridge-resources-02.patch
> > - verify_root_windows() should fail if there are no iomem _or_ ioport
> > resources, not only if there are no iomem _and_ ioport resources.
>
> This too.
Same one.
Thanks,
Dominik
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees
2005-06-26 20:14 ` Dominik Brodowski
@ 2005-06-27 20:18 ` Rajesh Shah
2005-06-27 20:26 ` Dominik Brodowski
0 siblings, 1 reply; 57+ messages in thread
From: Rajesh Shah @ 2005-06-27 20:18 UTC (permalink / raw)
To: Dominik Brodowski, Andrew Morton, greg, rajesh.shah, linux-kernel
On Sun, Jun 26, 2005 at 10:14:14PM +0200, Dominik Brodowski wrote:
> > Is this a recent regression? Is it only in -mm?
>
> Yes. Yes.
>
> > IOW: can you identify the bad patch? Or the bad patcher ;)
>
> gregkh-pci-pci-collect-host-bridge-resources-02.patch
>
Guilty as charged. I will look at providing a fix. In the meantime,
you can drop this patch if you like Andrew.
> > > - verify_root_windows() should fail if there are no iomem _or_ ioport
> > > resources, not only if there are no iomem _and_ ioport resources.
> >
No, I actually saw production (or close to production) machines
where BIOS was deliberately only programming memory resources, no
IO. In fact, I had to change the check to the current form for such
machines.
Rajesh
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees
2005-06-27 20:18 ` Rajesh Shah
@ 2005-06-27 20:26 ` Dominik Brodowski
0 siblings, 0 replies; 57+ messages in thread
From: Dominik Brodowski @ 2005-06-27 20:26 UTC (permalink / raw)
To: Rajesh Shah; +Cc: Andrew Morton, greg, linux-kernel
On Mon, Jun 27, 2005 at 01:18:11PM -0700, Rajesh Shah wrote:
> > > > - verify_root_windows() should fail if there are no iomem _or_ ioport
> > > > resources, not only if there are no iomem _and_ ioport resources.
> > >
>
> No, I actually saw production (or close to production) machines
> where BIOS was deliberately only programming memory resources, no
> IO. In fact, I had to change the check to the current form for such
> machines.
Well, what should be done in this case? IMO we should fall back to the
"previous" behaviour -- is a
kfree(bus->resource[i]);
bus->resource[i] = bres[i];
needed for this to happen?
Thanks,
Dominik
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees
2005-06-26 14:04 ` ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees Dominik Brodowski
2005-06-26 19:17 ` Andrew Morton
@ 2005-06-27 1:38 ` Grant Coady
2005-06-27 5:59 ` Dominik Brodowski
1 sibling, 1 reply; 57+ messages in thread
From: Grant Coady @ 2005-06-27 1:38 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: Andrew Morton, greg, rajesh.shah, linux-kernel
On Sun, 26 Jun 2005 16:04:12 +0200, Dominik Brodowski <linux@dominikbrodowski.net> wrote:
>On Sun, Jun 26, 2005 at 04:03:29AM -0700, Andrew Morton wrote:
>> - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
>> the recent PCI breakage sorted out.
>
>pci-yenta-cardbus-fix.patch and the following patch should solve the
>initialization time trouble. However, the ACPI-based PCI resource handling
>is badly broken, IMHO:
>
Well this patch doesn't do it for Toshiba laptop, ToPIC-100 ZV
bridge in 'auto' mode.
"-mm2b" info set on http://scatter.mine.nu/test/linux-2.6/tosh/
--- ioports-2.6.12.1a 2005-06-27 09:00:21.000000000 +1000
+++ ioports-2.6.12-mm2b 2005-06-27 09:54:45.000000000 +1000
@@ -10,20 +10,13 @@
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
-02f8-02ff : 0000:00:07.0
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vesafb
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
-1c00-1cff : 0000:00:07.0
-4000-40ff : PCI CardBus #02
- 4000-407f : 0000:02:00.0
- 4000-407f : xircom_cb
-4400-44ff : PCI CardBus #02
-fc00-fcff : 0000:00:0c.0
- fc00-fcff : ESS Maestro
+fc00-fcff : ESS Maestro
fd00-fd3f : motherboard
fe00-fe3f : 0000:00:05.3
fe00-fe3f : motherboard
@@ -40,8 +33,6 @@
fe90-fe97 : motherboard
fe9e-fe9e : motherboard
feac-feac : motherboard
-ff80-ff9f : 0000:00:05.2
- ff80-ff9f : uhci_hcd
-fff0-ffff : 0000:00:05.1
- fff0-fff7 : ide0
- fff8-ffff : ide1
+ff80-ff9f : uhci_hcd
+fff0-fff7 : ide0
+fff8-ffff : ide1
--Grant.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees
2005-06-27 1:38 ` Grant Coady
@ 2005-06-27 5:59 ` Dominik Brodowski
2005-06-27 8:55 ` Grant Coady
0 siblings, 1 reply; 57+ messages in thread
From: Dominik Brodowski @ 2005-06-27 5:59 UTC (permalink / raw)
To: Grant Coady; +Cc: Andrew Morton, greg, rajesh.shah, linux-kernel
On Mon, Jun 27, 2005 at 11:38:34AM +1000, Grant Coady wrote:
> On Sun, 26 Jun 2005 16:04:12 +0200, Dominik Brodowski <linux@dominikbrodowski.net> wrote:
>
> >On Sun, Jun 26, 2005 at 04:03:29AM -0700, Andrew Morton wrote:
> >> - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
> >> the recent PCI breakage sorted out.
> >
> >pci-yenta-cardbus-fix.patch and the following patch should solve the
> >initialization time trouble. However, the ACPI-based PCI resource handling
> >is badly broken, IMHO:
> >
>
> Well this patch doesn't do it for Toshiba laptop, ToPIC-100 ZV
> bridge in 'auto' mode.
Does reverting
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm2/broken-out/gregkh-pci-pci-collect-host-bridge-resources-02.patch
help in your case?
Dominik
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: 2.6.12-mm2
2005-06-26 11:03 2.6.12-mm2 Andrew Morton
` (2 preceding siblings ...)
2005-06-26 14:04 ` ACPI-based PCI resources: PCMCIA bugfix, but resources missing in trees Dominik Brodowski
@ 2005-06-26 14:18 ` Adam Kropelin
2005-06-26 19:25 ` 2.6.12-mm2 Andrew Morton
2005-06-26 16:05 ` [-mm patch] kernel/irq/autoprobe.c: remove an unused variable Adrian Bunk
` (4 subsequent siblings)
8 siblings, 1 reply; 57+ messages in thread
From: Adam Kropelin @ 2005-06-26 14:18 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Vojtech Pavlik, Greg KH, Dmitry Torokhov, '
I'd like to lobby for the merging into mainline of this patch from
git-input. It fixes a real bug, seen by real users, and has been
languishing in the input tree since March. It may also be a candidate
for the stable tree given it's one-linedness.
--
Fix extraction of HID items >= 32 bits
HID items of width 32 (bits) or greater are incorrectly extracted due to
a masking bug in hid-core.c:extract(). This patch fixes it up by forcing
the mask to be 64 bits wide.
Signed-off-by: Adam Kropelin <akropel1@rochester.rr.com>
--- linux-2.6.11/drivers/usb/input/hid-core.c Thu Mar 3 20:40:49 2005
+++ linux-2.6.11.adk/drivers/usb/input/hid-core.c Sun Mar 13 14:00:47 2005
@@ -757,7 +757,7 @@
static __inline__ __u32 extract(__u8 *report, unsigned offset, unsigned n)
{
report += (offset >> 5) << 2; offset &= 31;
- return (le64_to_cpu(get_unaligned((__le64*)report)) >> offset) & ((1 << n) - 1);
+ return (le64_to_cpu(get_unaligned((__le64*)report)) >> offset) & ((1ULL << n) - 1);
}
static __inline__ void implement(__u8 *report, unsigned offset, unsigned n, __u32 value)
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: 2.6.12-mm2
2005-06-26 14:18 ` 2.6.12-mm2 Adam Kropelin
@ 2005-06-26 19:25 ` Andrew Morton
2005-06-26 19:39 ` 2.6.12-mm2 Vojtech Pavlik
2005-06-27 13:13 ` 2.6.12-mm2 Vojtech Pavlik
0 siblings, 2 replies; 57+ messages in thread
From: Andrew Morton @ 2005-06-26 19:25 UTC (permalink / raw)
To: Adam Kropelin; +Cc: linux-kernel, vojtech, greg, dtor
Adam Kropelin <akropel1@rochester.rr.com> wrote:
>
> I'd like to lobby for the merging into mainline of this patch from
> git-input. It fixes a real bug, seen by real users, and has been
> languishing in the input tree since March. It may also be a candidate
> for the stable tree given it's one-linedness.
>
I think we can merge all of git-input into Linus's tree immediately.
But if that'll take some time then sure, we can merge up this little bit.
>
> Fix extraction of HID items >= 32 bits
>
> HID items of width 32 (bits) or greater are incorrectly extracted due to
> a masking bug in hid-core.c:extract(). This patch fixes it up by forcing
> the mask to be 64 bits wide.
>
>
> Signed-off-by: Adam Kropelin <akropel1@rochester.rr.com>
>
>
> --- linux-2.6.11/drivers/usb/input/hid-core.c Thu Mar 3 20:40:49 2005
> +++ linux-2.6.11.adk/drivers/usb/input/hid-core.c Sun Mar 13 14:00:47 2005
> @@ -757,7 +757,7 @@
> static __inline__ __u32 extract(__u8 *report, unsigned offset, unsigned n)
> {
> report += (offset >> 5) << 2; offset &= 31;
> - return (le64_to_cpu(get_unaligned((__le64*)report)) >> offset) & ((1 << n) - 1);
> + return (le64_to_cpu(get_unaligned((__le64*)report)) >> offset) & ((1ULL << n) - 1);
> }
>
> static __inline__ void implement(__u8 *report, unsigned offset, unsigned n, __u32 value)
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: 2.6.12-mm2
2005-06-26 19:25 ` 2.6.12-mm2 Andrew Morton
@ 2005-06-26 19:39 ` Vojtech Pavlik
2005-06-27 13:13 ` 2.6.12-mm2 Vojtech Pavlik
1 sibling, 0 replies; 57+ messages in thread
From: Vojtech Pavlik @ 2005-06-26 19:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: Adam Kropelin, linux-kernel, greg, dtor
On Sun, Jun 26, 2005 at 12:25:38PM -0700, Andrew Morton wrote:
> Adam Kropelin <akropel1@rochester.rr.com> wrote:
> >
> > I'd like to lobby for the merging into mainline of this patch from
> > git-input. It fixes a real bug, seen by real users, and has been
> > languishing in the input tree since March. It may also be a candidate
> > for the stable tree given it's one-linedness.
> >
>
> I think we can merge all of git-input into Linus's tree immediately.
>
> But if that'll take some time then sure, we can merge up this little bit.
I have some minor issues with a few of the patches. I'll take care of
that tomorrow, and then it can be merged to Linus.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: 2.6.12-mm2
2005-06-26 19:25 ` 2.6.12-mm2 Andrew Morton
2005-06-26 19:39 ` 2.6.12-mm2 Vojtech Pavlik
@ 2005-06-27 13:13 ` Vojtech Pavlik
1 sibling, 0 replies; 57+ messages in thread
From: Vojtech Pavlik @ 2005-06-27 13:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: Adam Kropelin, linux-kernel, greg, dtor
On Sun, Jun 26, 2005 at 12:25:38PM -0700, Andrew Morton wrote:
> > I'd like to lobby for the merging into mainline of this patch from
> > git-input. It fixes a real bug, seen by real users, and has been
> > languishing in the input tree since March. It may also be a candidate
> > for the stable tree given it's one-linedness.
>
> I think we can merge all of git-input into Linus's tree immediately.
I've checked it, the patches I had originally problems with are already
fixed, it's ready for merging.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 57+ messages in thread
* [-mm patch] kernel/irq/autoprobe.c: remove an unused variable
2005-06-26 11:03 2.6.12-mm2 Andrew Morton
` (3 preceding siblings ...)
2005-06-26 14:18 ` 2.6.12-mm2 Adam Kropelin
@ 2005-06-26 16:05 ` Adrian Bunk
2005-06-26 19:51 ` 2.6.12-mm2 Brice Goglin
` (3 subsequent siblings)
8 siblings, 0 replies; 57+ messages in thread
From: Adrian Bunk @ 2005-06-26 16:05 UTC (permalink / raw)
To: Andrew Morton, Luca Falavigna; +Cc: linux-kernel, Ingo Molnar, Jeff Garzik
On Sun, Jun 26, 2005 at 04:03:29AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.12-mm1:
>...
> +using-msleep-instead-of-hz.patch
>...
> cleanup
>...
This patch causes the following warning:
<-- snip -->
...
CC kernel/irq/autoprobe.o
kernel/irq/autoprobe.c: In function `probe_irq_on':
kernel/irq/autoprobe.c:30: warning: unused variable `delay'
...
<-- snip -->
This patch removes this no longer used variable.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.12-mm2-full/kernel/irq/autoprobe.c.old 2005-06-26 14:46:35.000000000 +0200
+++ linux-2.6.12-mm2-full/kernel/irq/autoprobe.c 2005-06-26 14:46:46.000000000 +0200
@@ -27,7 +27,7 @@
*/
unsigned long probe_irq_on(void)
{
- unsigned long val, delay;
+ unsigned long val;
irq_desc_t *desc;
unsigned int i;
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: 2.6.12-mm2
2005-06-26 11:03 2.6.12-mm2 Andrew Morton
` (4 preceding siblings ...)
2005-06-26 16:05 ` [-mm patch] kernel/irq/autoprobe.c: remove an unused variable Adrian Bunk
@ 2005-06-26 19:51 ` Brice Goglin
2005-06-27 0:44 ` 2.6.12-mm2 J.A. Magallon
` (2 subsequent siblings)
8 siblings, 0 replies; 57+ messages in thread
From: Brice Goglin @ 2005-06-26 19:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Le 26.06.2005 13:03, Andrew Morton a écrit :
> - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
> the recent PCI breakage sorted out.
Hi Andrew,
> +alsa-maestro3-div-by-zero-fix.patch
>
> Revert an alsa change which appears to cause a divide-by-zero.
I think you can now drop this one.
My "divide error" does not appear in -mm2.
It seems that it is fixed by the following patch:
> +revert-gregkh-pci-pci-assign-unassigned-resources.patch
>
> Revert a bad patch in it
To summarize, everything seems to now work fine on my Compaq Evo
N600c laptop. Both breakages I was seeing in -mm1 are now fixed:
* the maestro3 divide error does not appear anymore
* I reported a few days ago that my yenta hang was fixed
by pci-yenta-cardbus-fix.patch
Thanks,
Brice
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: 2.6.12-mm2
2005-06-26 11:03 2.6.12-mm2 Andrew Morton
` (5 preceding siblings ...)
2005-06-26 19:51 ` 2.6.12-mm2 Brice Goglin
@ 2005-06-27 0:44 ` J.A. Magallon
2005-06-27 0:56 ` 2.6.12-mm2 Andrew Morton
2005-06-27 2:50 ` Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2) Rogério Brito
2005-06-29 0:31 ` [sparc32] Kconfig fixups (was Re: 2.6.12-mm2) William Lee Irwin III
8 siblings, 1 reply; 57+ messages in thread
From: J.A. Magallon @ 2005-06-27 0:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On 06.26, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm2/
>
>
> - A reminder that there is a vger mailing list for tracking patches which
> are added to -mm. Do
>
> `echo subscribe mm-commits | mail majordomo@vger.kernel.org'
>
> - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
> the recent PCI breakage sorted out.
>
> - Big arch/cris update.
>
>
This is missing. Is it critical ?
--- 2.6.12/mm/memory.c 2005-06-17 20:48:29.000000000 +0100
+++ linux/mm/memory.c 2005-06-21 20:31:42.000000000 +0100
@@ -1051,7 +1051,7 @@ int remap_pfn_range(struct vm_area_struc
{
pgd_t *pgd;
unsigned long next;
- unsigned long end = addr + size;
+ unsigned long end = addr + PAGE_ALIGN(size);
struct mm_struct *mm = vma->vm_mm;
int err;
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam4 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: 2.6.12-mm2
2005-06-27 0:44 ` 2.6.12-mm2 J.A. Magallon
@ 2005-06-27 0:56 ` Andrew Morton
0 siblings, 0 replies; 57+ messages in thread
From: Andrew Morton @ 2005-06-27 0:56 UTC (permalink / raw)
To: J.A. Magallon; +Cc: linux-kernel
"J.A. Magallon" <jamagallon@able.es> wrote:
>
> This is missing. Is it critical ?
>
> --- 2.6.12/mm/memory.c 2005-06-17 20:48:29.000000000 +0100
> +++ linux/mm/memory.c 2005-06-21 20:31:42.000000000 +0100
> @@ -1051,7 +1051,7 @@ int remap_pfn_range(struct vm_area_struc
> {
> pgd_t *pgd;
> unsigned long next;
> - unsigned long end = addr + size;
> + unsigned long end = addr + PAGE_ALIGN(size);
> struct mm_struct *mm = vma->vm_mm;
> int err;
That's already in Linus's tree.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2)
2005-06-26 11:03 2.6.12-mm2 Andrew Morton
` (6 preceding siblings ...)
2005-06-27 0:44 ` 2.6.12-mm2 J.A. Magallon
@ 2005-06-27 2:50 ` Rogério Brito
2005-06-27 23:45 ` Andrew Morton
2005-06-29 0:31 ` [sparc32] Kconfig fixups (was Re: 2.6.12-mm2) William Lee Irwin III
8 siblings, 1 reply; 57+ messages in thread
From: Rogério Brito @ 2005-06-27 2:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hi, Andrew.
I am experiencing problems with -mm kernels and my firewire HD. I can use
it without any problems with Linus's 2.6.12, but I had problems with both
-mm1 and -mm2 (I just compiled -mm2 to see if the problem would go away,
but it didn't).
I am using the same .config file for all compiles, except that I wanted to
use the -mm tree for some things that I think would be orthogonal to the
issue (like using FUSE, for example).
I can't provide more details now, but as soon as I go to work with the
machine that presented the problem, I can give you all the details.
Essentially, what happens with -mm kernels that don't happen with Linus's
kernel is that the sbp2 module gets loaded, but it seems that the subsystem
never gets to actually see the partitions of the HD (I am using a HFS+
formatted disk for transfers of data between Linux and MacOS X).
If others also have the problem, I would like to know about it.
The Firewire controller that I am using is a vanilla VIA card and the HD is
a Seagate PATA HD in a Firewire enclosure (it's a ADS Tech DLX-185, if I am
not mistaken).
As I said, I can provide further details if wanted/needed.
Thanks for your work, Rogério.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2)
2005-06-27 2:50 ` Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2) Rogério Brito
@ 2005-06-27 23:45 ` Andrew Morton
2005-06-28 1:00 ` Rogério Brito
0 siblings, 1 reply; 57+ messages in thread
From: Andrew Morton @ 2005-06-27 23:45 UTC (permalink / raw)
To: Rogério Brito; +Cc: linux-kernel, linux1394-devel
(Added linux1394-devel)
Rogério Brito <rbrito@ime.usp.br> wrote:
>
> Hi, Andrew.
>
> I am experiencing problems with -mm kernels and my firewire HD. I can use
> it without any problems with Linus's 2.6.12, but I had problems with both
> -mm1 and -mm2 (I just compiled -mm2 to see if the problem would go away,
> but it didn't).
>
> I am using the same .config file for all compiles, except that I wanted to
> use the -mm tree for some things that I think would be orthogonal to the
> issue (like using FUSE, for example).
>
> I can't provide more details now, but as soon as I go to work with the
> machine that presented the problem, I can give you all the details.
>
> Essentially, what happens with -mm kernels that don't happen with Linus's
> kernel is that the sbp2 module gets loaded, but it seems that the subsystem
> never gets to actually see the partitions of the HD (I am using a HFS+
> formatted disk for transfers of data between Linux and MacOS X).
>
> If others also have the problem, I would like to know about it.
>
> The Firewire controller that I am using is a vanilla VIA card and the HD is
> a Seagate PATA HD in a Firewire enclosure (it's a ADS Tech DLX-185, if I am
> not mistaken).
>
> As I said, I can provide further details if wanted/needed.
>
>
Could you please generate the dmesg output from 2.6.12 and 2.6.12-mm2 and,
if there are any relevant-looking differences, send them?
Also, try:
wget ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm2/broken-out/gregkh-pci-pci-collect-host-bridge-resources-02.patch
patch -R -p1 < gregkh-pci-pci-collect-host-bridge-resources-02.patch
Thanks.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2)
2005-06-27 23:45 ` Andrew Morton
@ 2005-06-28 1:00 ` Rogério Brito
2005-06-28 2:22 ` Rogério Brito
2005-06-28 3:22 ` Andrew Morton
0 siblings, 2 replies; 57+ messages in thread
From: Rogério Brito @ 2005-06-28 1:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux1394-devel
On Jun 27 2005, Andrew Morton wrote:
> Could you please generate the dmesg output from 2.6.12 and 2.6.12-mm2 and,
> if there are any relevant-looking differences, send them?
Ok, I put them both on <http://www.ime.usp.br/~rbrito/bug/>.
> Also, try:
>
> wget (...)
> patch -R -p1 < gregkh-pci-pci-collect-host-bridge-resources-02.patch
Ok. I am compiling the kernel right now and will post the results as soon
as I am finished.
> Thanks.
Thank you very much for your feedback, Rogério.
P.S.: I just noticed right now that the patch listed above changes only
arch/i386/pci/acpi.c, but I am not using ACPI. Well, I will proceed anyway.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2)
2005-06-28 1:00 ` Rogério Brito
@ 2005-06-28 2:22 ` Rogério Brito
2005-06-28 3:22 ` Andrew Morton
1 sibling, 0 replies; 57+ messages in thread
From: Rogério Brito @ 2005-06-28 2:22 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux1394-devel
Hi, Andrew.
On Jun 27 2005, Rogério Brito wrote:
> Ok, I put them both on <http://www.ime.usp.br/~rbrito/bug/>.
(...)
> P.S.: I just noticed right now that the patch listed above changes only
> arch/i386/pci/acpi.c, but I am not using ACPI. Well, I will proceed anyway.
Well, as I felt before, backing out the patch didn't work. I posted the
dmesg of the new compilation on the page above like I did before.
Is there any other patch that I should try to revert?
Thanks, Rogério.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2)
2005-06-28 1:00 ` Rogério Brito
2005-06-28 2:22 ` Rogério Brito
@ 2005-06-28 3:22 ` Andrew Morton
2005-06-28 4:00 ` Ben Collins
2005-06-28 7:42 ` Stefan Richter
1 sibling, 2 replies; 57+ messages in thread
From: Andrew Morton @ 2005-06-28 3:22 UTC (permalink / raw)
To: Rogério Brito; +Cc: linux-kernel, linux1394-devel
Rogério Brito <rbrito@ime.usp.br> wrote:
>
> On Jun 27 2005, Andrew Morton wrote:
> > Could you please generate the dmesg output from 2.6.12 and 2.6.12-mm2 and,
> > if there are any relevant-looking differences, send them?
>
> Ok, I put them both on <http://www.ime.usp.br/~rbrito/bug/>.
Great, here we are:
-ieee1394: Node added: ID:BUS[0-00:1023] GUID[0050c501e00010e8]
+ieee1394: Node added: ID:BUS[0-01:1023] GUID[0050c501e00010e8]
+ieee1394: The root node is not cycle master capable; selecting a new root node and resetting...
+ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
SCSI subsystem initialized
sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>
@@ -300,14 +308,6 @@
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
Vendor: ST316002 Model: 1A Rev: 3.06
- Type: Direct-Access ANSI SCSI revision: 06
-SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
-sda: asking for cache data failed
-sda: assuming drive cache: write through
-SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
-sda: asking for cache data failed
-sda: assuming drive cache: write through
- sda: [mac] sda1 sda2 sda3 sda4
-Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
+ Type: Unknown ANSI SCSI revision: 04
ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0050c501e00010e8]
Could the 1394 guys please suggest what might have caused this?
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2)
2005-06-28 3:22 ` Andrew Morton
@ 2005-06-28 4:00 ` Ben Collins
2005-06-28 6:12 ` Rogério Brito
2005-06-28 7:42 ` Stefan Richter
1 sibling, 1 reply; 57+ messages in thread
From: Ben Collins @ 2005-06-28 4:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: Rog?rio Brito, linux-kernel, linux1394-devel
> Could the 1394 guys please suggest what might have caused this?
Unless something is in git that isn't in subversion, nothing has really
changed in the sbp2 module for 5-6 months.
Doesn't appear to be a problem with the ieee1394 subsystem itself (the
cycle master thing isn't all that important), since that would cause not
even being able to send/recv packets.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk - http://www.swissdisk.com/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2)
2005-06-28 4:00 ` Ben Collins
@ 2005-06-28 6:12 ` Rogério Brito
2005-06-28 16:15 ` Ben Collins
0 siblings, 1 reply; 57+ messages in thread
From: Rogério Brito @ 2005-06-28 6:12 UTC (permalink / raw)
To: Ben Collins; +Cc: Andrew Morton, linux-kernel, linux1394-devel
On Jun 28 2005, Ben Collins wrote:
> Unless something is in git that isn't in subversion, nothing has really
> changed in the sbp2 module for 5-6 months.
Is there any other information that I can provide you with that would help
track this?
> Doesn't appear to be a problem with the ieee1394 subsystem itself (the
> cycle master thing isn't all that important), since that would cause not
> even being able to send/recv packets.
So, could this be a problem with the SCSI layer, then?
Thank you, Rogério.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2)
2005-06-28 6:12 ` Rogério Brito
@ 2005-06-28 16:15 ` Ben Collins
2005-07-01 1:01 ` Problems with Firewire and -mm kernels Rogério Brito
0 siblings, 1 reply; 57+ messages in thread
From: Ben Collins @ 2005-06-28 16:15 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux1394-devel
On Tue, Jun 28, 2005 at 03:12:45AM -0300, Rog?rio Brito wrote:
> On Jun 28 2005, Ben Collins wrote:
> > Unless something is in git that isn't in subversion, nothing has really
> > changed in the sbp2 module for 5-6 months.
>
> Is there any other information that I can provide you with that would help
> track this?
Diff git2's ieee1394 directory and the SVN repo from linux1394.org if you
could.
> > Doesn't appear to be a problem with the ieee1394 subsystem itself (the
> > cycle master thing isn't all that important), since that would cause not
> > even being able to send/recv packets.
>
> So, could this be a problem with the SCSI layer, then?
Doubtful.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk - http://www.swissdisk.com/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-06-28 16:15 ` Ben Collins
@ 2005-07-01 1:01 ` Rogério Brito
2005-07-01 1:12 ` Ben Collins
0 siblings, 1 reply; 57+ messages in thread
From: Rogério Brito @ 2005-07-01 1:01 UTC (permalink / raw)
To: Ben Collins; +Cc: Andrew Morton, Stefan Richter, linux-kernel, linux1394-devel
On Jun 28 2005, Ben Collins wrote:
> On Tue, Jun 28, 2005 at 03:12:45AM -0300, Rog?rio Brito wrote:
> > Is there any other information that I can provide you with that would help
> > track this?
>
> Diff git2's ieee1394 directory and the SVN repo from linux1394.org if you
> could.
Ok, I see that this is getting to be really important now, because I think
that Andrew forwarded some patches to Linus and now the Firewire enclosure
doesn't seem to work with 2.6.13-rc1 anymore (it works perfectly with
vanilla kernel 2.6.12).
The behaviour that I get with 2.6.13-rc1 is the same one that I got with
2.6.12-mm1 or 2.6.12-mm2. :-(
Oh, BTW, I just checked this with another drive, an iPod (2nd Generation)
and its partition table is also not read (like what happens with the drive
in the Firewire enclosure).
So, I guess that this is another data point that may be useful.
Thank you very much for your help, Rogério.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-07-01 1:01 ` Problems with Firewire and -mm kernels Rogério Brito
@ 2005-07-01 1:12 ` Ben Collins
2005-07-01 2:23 ` Rogério Brito
` (2 more replies)
0 siblings, 3 replies; 57+ messages in thread
From: Ben Collins @ 2005-07-01 1:12 UTC (permalink / raw)
To: rbrito; +Cc: Andrew Morton, Stefan Richter, linux-kernel, linux1394-devel
On Thu, Jun 30, 2005 at 10:01:57PM -0300, Rog?rio Brito wrote:
> On Jun 28 2005, Ben Collins wrote:
> > On Tue, Jun 28, 2005 at 03:12:45AM -0300, Rog?rio Brito wrote:
> > > Is there any other information that I can provide you with that would help
> > > track this?
> >
> > Diff git2's ieee1394 directory and the SVN repo from linux1394.org if you
> > could.
Where are these patches coming from? Also, have you tried using 2.6.13-rc1
using linux1394.org's subversion tree?
> Ok, I see that this is getting to be really important now, because I think
> that Andrew forwarded some patches to Linus and now the Firewire enclosure
> doesn't seem to work with 2.6.13-rc1 anymore (it works perfectly with
> vanilla kernel 2.6.12).
>
> The behaviour that I get with 2.6.13-rc1 is the same one that I got with
> 2.6.12-mm1 or 2.6.12-mm2. :-(
>
> Oh, BTW, I just checked this with another drive, an iPod (2nd Generation)
> and its partition table is also not read (like what happens with the drive
> in the Firewire enclosure).
>
> So, I guess that this is another data point that may be useful.
>
>
> Thank you very much for your help, Rog?rio.
>
> --
> Rog?rio Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
> Homepage of the algorithms package : http://algorithms.berlios.de
> Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk - http://www.swissdisk.com/
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: Problems with Firewire and -mm kernels
2005-07-01 1:12 ` Ben Collins
@ 2005-07-01 2:23 ` Rogério Brito
2005-07-01 2:28 ` Problems with Firewire and -mm kernels (and vanilla 2.6.13-rc1) Rogério Brito
2005-07-01 2:44 ` Problems with Firewire and -mm kernels Rogério Brito
2 siblings, 0 replies; 57+ messages in thread
From: Rogério Brito @ 2005-07-01 2:23 UTC (permalink / raw)
To: Ben Collins; +Cc: Andrew Morton, Stefan Richter, linux-kernel, linux1394-devel
On Jun 30 2005, Ben Collins wrote:
> On Thu, Jun 30, 2005 at 10:01:57PM -0300, Rog?rio Brito wrote:
> > On Jun 28 2005, Ben Collins wrote:
> > > On Tue, Jun 28, 2005 at 03:12:45AM -0300, Rog?rio Brito wrote:
> > > > Is there any other information that I can provide you with that would help
> > > > track this?
> > >
> > > Diff git2's ieee1394 directory and the SVN repo from linux1394.org if you
> > > could.
>
> Where are these patches coming from? Also, have you tried using 2.6.13-rc1
> using linux1394.org's subversion tree?
I don't know where the patches are coming from. I have just checked out the
trunk version of the subversion tree from linux1394.org. I will diff it
against the Linux tree that I have here.
Humm, I have just diffed both trees and there is a fair amount of changes
between both versions (i.e., between Linux 2.6.13-rc1 and the trunk tree
from linux1394.org).
The diff (in this order) is at http://www.ime.usp.br/~rbrito/bug/, if you
can comment on it.
I can provide any other information that is needed. Just let me know what
is desired.
Thank you very much, Rogério.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels (and vanilla 2.6.13-rc1)
2005-07-01 1:12 ` Ben Collins
2005-07-01 2:23 ` Rogério Brito
@ 2005-07-01 2:28 ` Rogério Brito
2005-07-01 2:44 ` Problems with Firewire and -mm kernels Rogério Brito
2 siblings, 0 replies; 57+ messages in thread
From: Rogério Brito @ 2005-07-01 2:28 UTC (permalink / raw)
To: Ben Collins; +Cc: Andrew Morton, Stefan Richter, linux-kernel, linux1394-devel
On Jun 30 2005, Ben Collins wrote:
> Also, have you tried using 2.6.13-rc1 using linux1394.org's subversion tree?
I am doing this right now. I will let you know the resuts as soon as I get
the kernel compiled.
Thanks, Rogério.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-07-01 1:12 ` Ben Collins
2005-07-01 2:23 ` Rogério Brito
2005-07-01 2:28 ` Problems with Firewire and -mm kernels (and vanilla 2.6.13-rc1) Rogério Brito
@ 2005-07-01 2:44 ` Rogério Brito
2005-07-01 3:18 ` Ben Collins
2 siblings, 1 reply; 57+ messages in thread
From: Rogério Brito @ 2005-07-01 2:44 UTC (permalink / raw)
To: Ben Collins; +Cc: Andrew Morton, Stefan Richter, linux-kernel, linux1394-devel
On Jun 30 2005, Ben Collins wrote:
> Also, have you tried using 2.6.13-rc1 using linux1394.org's subversion tree?
Here is what I get when I try to substitute 2.6.13-rc1 with linux1394
trunk's tree:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(...)
CC [M] drivers/block/loop.o
CC [M] drivers/block/pktcdvd.o
CC [M] drivers/block/cryptoloop.o
CC [M] drivers/char/agp/intel-agp.o
CC [M] drivers/ieee1394/ieee1394_core.o
drivers/ieee1394/ieee1394_core.c: In function `hpsbpkt_thread':
drivers/ieee1394/ieee1394_core.c:1048: error: too many arguments to function `refrigerator'
drivers/ieee1394/ieee1394_core.c: In function `ieee1394_init':
drivers/ieee1394/ieee1394_core.c:1127: warning: implicit declaration of function `class_simple_create'
drivers/ieee1394/ieee1394_core.c:1127: warning: assignment makes pointer from integer without a cast
drivers/ieee1394/ieee1394_core.c:1165: warning: implicit declaration of function `class_simple_destroy'
make[3]: *** [drivers/ieee1394/ieee1394_core.o] Error 1
make[2]: *** [drivers/ieee1394] Error 2
make[1]: *** [drivers] Error 2
make[1]: Leaving directory `/usr/local/media/progs/linux/linux'
make: *** [stamp-build] Error 2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Thanks, Rogério Brito.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-07-01 2:44 ` Problems with Firewire and -mm kernels Rogério Brito
@ 2005-07-01 3:18 ` Ben Collins
2005-07-01 4:01 ` Dan Dennedy
` (2 more replies)
0 siblings, 3 replies; 57+ messages in thread
From: Ben Collins @ 2005-07-01 3:18 UTC (permalink / raw)
To: rbrito; +Cc: Andrew Morton, Stefan Richter, linux-kernel, linux1394-devel
Most of this is class_simple changes.
However, there is a huge set of changes to sbp2. One thing that sticks out
is the entire sbp2_check_sbp2_command() function being ripped out. There's
some changes related to TYPE_SDAD devices (where did this come from?).
Try reverting just the sbp2.[ch] changes from the 2.6.13-rc1 tree.
I'll see if I can figure out why our tree and kernel tree have gotten so
far out of whack and how such huge changes that don't seem to fix anything
(like the large changes to sbp2) have gotten into the kernel proper
without being tested. Most of the sbp2 changes seem to be a new feature
rather than fixing minor or even major bugs.
On Thu, Jun 30, 2005 at 11:44:33PM -0300, Rog?rio Brito wrote:
> On Jun 30 2005, Ben Collins wrote:
> > Also, have you tried using 2.6.13-rc1 using linux1394.org's subversion tree?
>
> Here is what I get when I try to substitute 2.6.13-rc1 with linux1394
> trunk's tree:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> (...)
> CC [M] drivers/block/loop.o
> CC [M] drivers/block/pktcdvd.o
> CC [M] drivers/block/cryptoloop.o
> CC [M] drivers/char/agp/intel-agp.o
> CC [M] drivers/ieee1394/ieee1394_core.o
> drivers/ieee1394/ieee1394_core.c: In function `hpsbpkt_thread':
> drivers/ieee1394/ieee1394_core.c:1048: error: too many arguments to function `refrigerator'
> drivers/ieee1394/ieee1394_core.c: In function `ieee1394_init':
> drivers/ieee1394/ieee1394_core.c:1127: warning: implicit declaration of function `class_simple_create'
> drivers/ieee1394/ieee1394_core.c:1127: warning: assignment makes pointer from integer without a cast
> drivers/ieee1394/ieee1394_core.c:1165: warning: implicit declaration of function `class_simple_destroy'
> make[3]: *** [drivers/ieee1394/ieee1394_core.o] Error 1
> make[2]: *** [drivers/ieee1394] Error 2
> make[1]: *** [drivers] Error 2
> make[1]: Leaving directory `/usr/local/media/progs/linux/linux'
> make: *** [stamp-build] Error 2
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Thanks, Rog?rio Brito.
>
> --
> Rog?rio Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
> Homepage of the algorithms package : http://algorithms.berlios.de
> Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk - http://www.swissdisk.com/
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: Problems with Firewire and -mm kernels
2005-07-01 3:18 ` Ben Collins
@ 2005-07-01 4:01 ` Dan Dennedy
2005-07-01 4:37 ` Stefan Richter
2005-07-01 4:12 ` Stefan Richter
2005-07-01 4:30 ` Rogério Brito
2 siblings, 1 reply; 57+ messages in thread
From: Dan Dennedy @ 2005-07-01 4:01 UTC (permalink / raw)
To: Ben Collins
Cc: rbrito, Andrew Morton, Stefan Richter, linux-kernel,
linux1394-devel
On Thu, 2005-06-30 at 23:18 -0400, Ben Collins wrote:
> Most of this is class_simple changes.
>
> However, there is a huge set of changes to sbp2. One thing that sticks out
> is the entire sbp2_check_sbp2_command() function being ripped out. There's
> some changes related to TYPE_SDAD devices (where did this come from?).
This is the TYPE_RBC cache fixes patch by Al Viro. That discussion went
on for a while with additional changes suggested, and I did not know the
resolution. Now we do. :-)
> Try reverting just the sbp2.[ch] changes from the 2.6.13-rc1 tree.
>
> I'll see if I can figure out why our tree and kernel tree have gotten so
> far out of whack and how such huge changes that don't seem to fix anything
Obviously, much of the diff Rogerio produced (not in history below)
shows changes in our repo not yet submitted to kernel.
> (like the large changes to sbp2) have gotten into the kernel proper
> without being tested. Most of the sbp2 changes seem to be a new feature
> rather than fixing minor or even major bugs.
>
> On Thu, Jun 30, 2005 at 11:44:33PM -0300, Rog?rio Brito wrote:
> > On Jun 30 2005, Ben Collins wrote:
> > > Also, have you tried using 2.6.13-rc1 using linux1394.org's subversion tree?
> >
> > Here is what I get when I try to substitute 2.6.13-rc1 with linux1394
> > trunk's tree:
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > (...)
> > CC [M] drivers/block/loop.o
> > CC [M] drivers/block/pktcdvd.o
> > CC [M] drivers/block/cryptoloop.o
> > CC [M] drivers/char/agp/intel-agp.o
> > CC [M] drivers/ieee1394/ieee1394_core.o
> > drivers/ieee1394/ieee1394_core.c: In function `hpsbpkt_thread':
> > drivers/ieee1394/ieee1394_core.c:1048: error: too many arguments to function `refrigerator'
> > drivers/ieee1394/ieee1394_core.c: In function `ieee1394_init':
> > drivers/ieee1394/ieee1394_core.c:1127: warning: implicit declaration of function `class_simple_create'
> > drivers/ieee1394/ieee1394_core.c:1127: warning: assignment makes pointer from integer without a cast
> > drivers/ieee1394/ieee1394_core.c:1165: warning: implicit declaration of function `class_simple_destroy'
> > make[3]: *** [drivers/ieee1394/ieee1394_core.o] Error 1
> > make[2]: *** [drivers/ieee1394] Error 2
> > make[1]: *** [drivers] Error 2
> > make[1]: Leaving directory `/usr/local/media/progs/linux/linux'
> > make: *** [stamp-build] Error 2
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> > Thanks, Rog?rio Brito.
> >
> > --
> > Rog?rio Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
> > Homepage of the algorithms package : http://algorithms.berlios.de
> > Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-07-01 3:18 ` Ben Collins
2005-07-01 4:01 ` Dan Dennedy
@ 2005-07-01 4:12 ` Stefan Richter
2005-07-01 4:30 ` Rogério Brito
2 siblings, 0 replies; 57+ messages in thread
From: Stefan Richter @ 2005-07-01 4:12 UTC (permalink / raw)
To: linux-kernel, linux1394-devel; +Cc: Ben Collins, rbrito, Andrew Morton
Ben Collins wrote:
> However, there is a huge set of changes to sbp2. One thing that sticks out
> is the entire sbp2_check_sbp2_command() function being ripped out. There's
> some changes related to TYPE_SDAD devices (where did this come from?).
The TYPE_SDAD -> TYPE_RBC changes come from the scsi maintainers. Here
is the related discussion from May: 'TYPE_RBC cache fixes (sbp2.c
affected)', http://marc.theaimsgroup.com/?t=111620896500001
(Back then I wanted to test their patch but did not find the time.)
--
Stefan Richter
-=====-=-=-= -=== ----=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-07-01 3:18 ` Ben Collins
2005-07-01 4:01 ` Dan Dennedy
2005-07-01 4:12 ` Stefan Richter
@ 2005-07-01 4:30 ` Rogério Brito
2005-07-01 5:15 ` Ben Collins
2 siblings, 1 reply; 57+ messages in thread
From: Rogério Brito @ 2005-07-01 4:30 UTC (permalink / raw)
To: Ben Collins; +Cc: Andrew Morton, Stefan Richter, linux-kernel, linux1394-devel
On Jun 30 2005, Ben Collins wrote:
> Try reverting just the sbp2.[ch] changes from the 2.6.13-rc1 tree.
Ok, I did that and it worked fine, thanks! I'm trying to upload the
resulting dmesg so that you can see yourself, but it seems that my
University's site isn't working for some reason. :-(
Oh, I got one warning when I was compiling sbp2.c (it was something like an
invalid initialization around line 27xx--yes, yes, I know that this doesn't
help much, but I don't have the log of the compilation here).
> I'll see if I can figure out why our tree and kernel tree have gotten so
> far out of whack and how such huge changes that don't seem to fix
> anything (like the large changes to sbp2) have gotten into the kernel
> proper without being tested. Most of the sbp2 changes seem to be a new
> feature rather than fixing minor or even major bugs.
Yes, it would help a lot if the fixes were included in 2.6.13 (final).
Thank you very much again, Rogério Brito.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-07-01 4:30 ` Rogério Brito
@ 2005-07-01 5:15 ` Ben Collins
0 siblings, 0 replies; 57+ messages in thread
From: Ben Collins @ 2005-07-01 5:15 UTC (permalink / raw)
To: Andrew Morton, Stefan Richter, linux-kernel, linux1394-devel
On Fri, Jul 01, 2005 at 01:30:39AM -0300, Rog?rio Brito wrote:
> On Jun 30 2005, Ben Collins wrote:
> > Try reverting just the sbp2.[ch] changes from the 2.6.13-rc1 tree.
>
> Ok, I did that and it worked fine, thanks! I'm trying to upload the
> resulting dmesg so that you can see yourself, but it seems that my
> University's site isn't working for some reason. :-(
>
> Oh, I got one warning when I was compiling sbp2.c (it was something like an
> invalid initialization around line 27xx--yes, yes, I know that this doesn't
> help much, but I don't have the log of the compilation here).
Ok, so the TYPE_SDAD/TYPE_RBC changes did affect sbp2. I think the changes
look a little much for what it was trying to accomplish (moving code
around between functions and changing logic paths is a little much when no
one tests it).
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk - http://www.swissdisk.com/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-06-28 3:22 ` Andrew Morton
2005-06-28 4:00 ` Ben Collins
@ 2005-06-28 7:42 ` Stefan Richter
2005-06-28 7:46 ` Andrew Morton
` (2 more replies)
1 sibling, 3 replies; 57+ messages in thread
From: Stefan Richter @ 2005-06-28 7:42 UTC (permalink / raw)
To: linux-kernel, linux1394-devel; +Cc: Andrew Morton, Rogério Brito
Andrew Morton wrote:
> -ieee1394: Node added: ID:BUS[0-00:1023] GUID[0050c501e00010e8]
> +ieee1394: Node added: ID:BUS[0-01:1023] GUID[0050c501e00010e8]
> +ieee1394: The root node is not cycle master capable; selecting a new root node and resetting...
> +ieee1394: Node changed: 0-01:1023 -> 0-00:1023
> ieee1394: Node changed: 0-00:1023 -> 0-01:1023
The IDs are assigned to nodes everytime they are attached to the bus in
a random order. It is a pure hardware thing; I cannot imagine any
influnce of the kernel to this procedure.
If the node with the highest ID does not fulfill certain criteria, Linux
tries to get the highest ID moved to the local node. This function is
unrelated to SBP-2 (it is necessary to let streaming devices like
cameras work) but it has been observed that it disturbs a few SBP-2
devices. But again, I don't see how -mm and the stock kernel should
differ to that respect.
You could load ieee1394 with a new parameter that supresses the "Root
node is not cycle master capable..." routine:
# modprobe ieee1394 disable_irm=1
before ohci1394 and the other 1394 related drivers are loaded.
> SCSI subsystem initialized
> sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>
> @@ -300,14 +308,6 @@
> ieee1394: sbp2: Logged into SBP-2 device
> ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
> Vendor: ST316002 Model: 1A Rev: 3.06
> - Type: Direct-Access ANSI SCSI revision: 06
> -SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
> -sda: asking for cache data failed
> -sda: assuming drive cache: write through
> -SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
> -sda: asking for cache data failed
> -sda: assuming drive cache: write through
> - sda: [mac] sda1 sda2 sda3 sda4
> -Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> + Type: Unknown ANSI SCSI revision: 04
There was a discussion in May about discovery of devices which implement
the RBC command set: http://marc.theaimsgroup.com/?t=111620896500001 I
am not sure if the discussed change went into one or both of the kernels
in question.
> ieee1394: Node changed: 0-01:1023 -> 0-00:1023
> ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0050c501e00010e8]
What caused these two messages? Did you disconnect the drive at this point?
--
Stefan Richter
-=====-=-=-= -==- ===--
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: Problems with Firewire and -mm kernels
2005-06-28 7:42 ` Stefan Richter
@ 2005-06-28 7:46 ` Andrew Morton
2005-06-28 8:37 ` Rogério Brito
2005-06-28 16:38 ` Giuseppe Bilotta
2005-06-28 8:18 ` Rogério Brito
2005-06-30 0:43 ` Rogério Brito
2 siblings, 2 replies; 57+ messages in thread
From: Andrew Morton @ 2005-06-28 7:46 UTC (permalink / raw)
To: linux-kernel, linux1394-devel
Cc: stefanr, linux-kernel, linux1394-devel, rbrito
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>
> > ieee1394: Node changed: 0-01:1023 -> 0-00:1023
> > ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0050c501e00010e8]
>
> What caused these two messages? Did you disconnect the drive at this point?
No, there is no device plugged into the machine.
Maybe the G5 has some internal 1394 device? It would be news to me if so.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-06-28 7:46 ` Andrew Morton
@ 2005-06-28 8:37 ` Rogério Brito
2005-06-28 16:25 ` Ben Collins
2005-06-28 16:38 ` Giuseppe Bilotta
1 sibling, 1 reply; 57+ messages in thread
From: Rogério Brito @ 2005-06-28 8:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux1394-devel, stefanr
On Jun 28 2005, Andrew Morton wrote:
> Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> >
> > > ieee1394: Node changed: 0-01:1023 -> 0-00:1023
> > > ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0050c501e00010e8]
> >
> > What caused these two messages? Did you disconnect the drive at this
> > point?
>
> No, there is no device plugged into the machine.
Right, at that time I had already disconnected the drive.
> Maybe the G5 has some internal 1394 device? It would be news to me if so.
Heh, I don't have the money for a G5. :-) I'm using this on a vanilla x86
with a Duron 1.1GHz (which I recently upgraded from a Duron 600MHz).
Perhaps I should provide more information regarding my system? If yes,
please let me know what and I will do my best.
Thanks, Rogério.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-06-28 7:46 ` Andrew Morton
2005-06-28 8:37 ` Rogério Brito
@ 2005-06-28 16:38 ` Giuseppe Bilotta
1 sibling, 0 replies; 57+ messages in thread
From: Giuseppe Bilotta @ 2005-06-28 16:38 UTC (permalink / raw)
To: linux-kernel; +Cc: linux1394-devel
On Tue, 28 Jun 2005 00:46:50 -0700, Andrew Morton wrote:
> Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>>
>>> ieee1394: Node changed: 0-01:1023 -> 0-00:1023
>> > ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0050c501e00010e8]
>>
>> What caused these two messages? Did you disconnect the drive at this point?
>
> No, there is no device plugged into the machine.
>
> Maybe the G5 has some internal 1394 device? It would be news to me if so.
Well, I would assume the Macs play some trick with the internal
Firewire and IDE/SCSI channels to allow the internal hard disk to come
up as firewire hard disks for other Macs when in Target mode. So maybe
that's the result of this?
--
Giuseppe "Oblomov" Bilotta
"Da grande lotterò per la pace"
"A me me la compra il mio babbo"
(Altan)
("When I grow up, I will fight for peace"
"I'll have my daddy buy it for me")
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-06-28 7:42 ` Stefan Richter
2005-06-28 7:46 ` Andrew Morton
@ 2005-06-28 8:18 ` Rogério Brito
2005-06-28 18:47 ` Stefan Richter
2005-06-30 0:43 ` Rogério Brito
2 siblings, 1 reply; 57+ messages in thread
From: Rogério Brito @ 2005-06-28 8:18 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux-kernel, linux1394-devel, Andrew Morton
On Jun 28 2005, Stefan Richter wrote:
> But again, I don't see how -mm and the stock kernel should differ to that
> respect.
Well, I can only say that this problem is 100% reproducible with my
enclosure.
Perhaps more data is needed here? The 2.6.12 kernel is able to see the
drive without any problems while the -mm kernels aren't. I can provide
anything that you guys want.
Right now, I am using a stock/vanilla kernel, for using the drive.
> You could load ieee1394 with a new parameter that supresses the "Root
> node is not cycle master capable..." routine:
> # modprobe ieee1394 disable_irm=1
> before ohci1394 and the other 1394 related drivers are loaded.
Ok, I'll disable hotplug, udev etc and try to boot into single user mode
for that as soon as I wake up (I'm going to bed right now---had a lot of
work done for a day).
> > ieee1394: Node changed: 0-01:1023 -> 0-00:1023
> > ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0050c501e00010e8]
>
> What caused these two messages? Did you disconnect the drive at this
> point?
Yes, I did. In both cases, just to see if any messages issued to dmesg were
different when unplugging the drive.
If you have other ideas or if any extra information is necessary, please,
let me know and I'll do my best to provide what you need.
Thank you all for the interest, Rogério.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-06-28 8:18 ` Rogério Brito
@ 2005-06-28 18:47 ` Stefan Richter
0 siblings, 0 replies; 57+ messages in thread
From: Stefan Richter @ 2005-06-28 18:47 UTC (permalink / raw)
To: linux-kernel, linux1394-devel; +Cc: Rogério Brito, Andrew Morton
Rogério Brito wrote:
> On Jun 28 2005, Stefan Richter wrote:
>>But again, I don't see how -mm and the stock kernel should differ to that
>>respect.
>
> Well, I can only say that this problem is 100% reproducible with my
> enclosure.
>
> Perhaps more data is needed here? The 2.6.12 kernel is able to see the
> drive without any problems while the -mm kernels aren't. I can provide
> anything that you guys want.
What we know is:
- With -mm, your machine started to require the switching of phy IDs
for a proper cycle master.
- With -mm, the device formerly sensed by scsi_mod's probe as
"Direct-Access" device + SCSI rev 06 is allegedly of "Unknown" type +
SCSI rev 04 now. Vendor and model are still recognized though.
So what we don't know at the moment is:
- What did change to make the formerly "unlikely to happen" FireWire
bus reset "extremely likely to happen" now? (That is how I interpret
the ratio of 0% to 100% which you observed.)
- Does this reset infuence how the device answers to scsi inquiries?
So far there were only reports on the linux1394 mailinglists
indicating that with this reset, devices respond differently to
config ROM queries from the ieee1394 driver. This is way before sbp2
and scsi_mod get to know about the device.
My current uneducated guess is that the FireWire bus reset and the SCSI
probing problem are actually unrelated. The cause for the latter problem
might be 2.6.12-mm2/broken-out/git-scsi-block.patch. At least that is
what I think after a look through the -mm2 patch collection.
>>You could load ieee1394 with a new parameter that supresses the "Root
>>node is not cycle master capable..." routine:
>># modprobe ieee1394 disable_irm=1
>>before ohci1394 and the other 1394 related drivers are loaded.
>
> Ok, I'll disable hotplug, udev etc and try to boot into single user mode
> for that as soon as I wake up (I'm going to bed right now---had a lot of
> work done for a day).
You do not need to go through all this. Unload all 1394 drivers
(although this may fail sometimes when scsi does not let go of sbp2),
then reload ieee1394 with the parameter, then ohci1394. No need to go
into another runlevel or to mess around with hotplug or udev.
>>>ieee1394: Node changed: 0-01:1023 -> 0-00:1023
>>>ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0050c501e00010e8]
>>
>>What caused these two messages? Did you disconnect the drive at this
>>point?
>
> Yes, I did. In both cases, just to see if any messages issued to dmesg were
> different when unplugging the drive.
Then these two messages are OK.
--
Stefan Richter
-=====-=-=-= -==- ===--
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Problems with Firewire and -mm kernels
2005-06-28 7:42 ` Stefan Richter
2005-06-28 7:46 ` Andrew Morton
2005-06-28 8:18 ` Rogério Brito
@ 2005-06-30 0:43 ` Rogério Brito
2 siblings, 0 replies; 57+ messages in thread
From: Rogério Brito @ 2005-06-30 0:43 UTC (permalink / raw)
To: stefanr; +Cc: linux-kernel, linux1394-devel, akpm, bcollins
On Jun 28 2005, Stefan Richter wrote:
> If the node with the highest ID does not fulfill certain criteria, Linux
> tries to get the highest ID moved to the local node. This function is
> unrelated to SBP-2 (it is necessary to let streaming devices like
> cameras work) but it has been observed that it disturbs a few SBP-2
> devices. But again, I don't see how -mm and the stock kernel should
> differ to that respect.
Well, my observation is that they differ. Well, up to kernel 2.6.13-rc1.
This latest kernel shows the same behaviour that -mm showed, unfortunately.
> You could load ieee1394 with a new parameter that supresses the "Root
> node is not cycle master capable..." routine:
> # modprobe ieee1394 disable_irm=1
> before ohci1394 and the other 1394 related drivers are loaded.
Now *this* made things work! I have put another dmesg log on my homepage at
http://www.ime.usp.br/~rbrito/bug/ (see the 3rd-try log). This made things
work and I could mount the device.
I had to disable hotplug and udev, since trying to unload the Firewire
modules made my machine hang (I think that it was trying to unload ohci1394
that made my machine hang).
So, does this ring any bell? Can I provide extra information?
I am keeping the following diff just for reference's sake:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> SCSI subsystem initialized
> sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>
>@@ -300,14 +308,6 @@
> ieee1394: sbp2: Logged into SBP-2 device
> ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
> Vendor: ST316002 Model: 1A Rev: 3.06
>- Type: Direct-Access ANSI SCSI revision: 06
>-SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
>-sda: asking for cache data failed
>-sda: assuming drive cache: write through
>-SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
>-sda: asking for cache data failed
>-sda: assuming drive cache: write through
>- sda: [mac] sda1 sda2 sda3 sda4
>-Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
>+ Type: Unknown ANSI SCSI revision: 04
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Thanks for all your kind responses, Rogério Brito.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
^ permalink raw reply [flat|nested] 57+ messages in thread
* [sparc32] Kconfig fixups (was Re: 2.6.12-mm2)
2005-06-26 11:03 2.6.12-mm2 Andrew Morton
` (7 preceding siblings ...)
2005-06-27 2:50 ` Problems with Firewire and -mm kernels (was: Re: 2.6.12-mm2) Rogério Brito
@ 2005-06-29 0:31 ` William Lee Irwin III
8 siblings, 0 replies; 57+ messages in thread
From: William Lee Irwin III @ 2005-06-29 0:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sun, Jun 26, 2005 at 04:03:29AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm2/
Something reverted most of the arch/sparc/Kconfig changes, leaving
arch/sparc/ unconfigurable. This patch re-removes the parts made
redundant by drivers/Kconfig in addition to a mysterious, spurious
second instance of source "mm/Kconfig". cvs strikes again?
Signed-off-by: William Irwin <wli@holomorphy.com>
Index: mm2-2.6.12/arch/sparc/Kconfig
===================================================================
--- mm2-2.6.12.orig/arch/sparc/Kconfig 2005-06-28 17:06:54.655102470 -0700
+++ mm2-2.6.12/arch/sparc/Kconfig 2005-06-28 17:16:52.135271678 -0700
@@ -270,66 +270,10 @@
source "drivers/Kconfig"
-config PRINTER
- tristate "Parallel printer support"
- depends on PARPORT
- ---help---
- If you intend to attach a printer to the parallel port of your Linux
- box (as opposed to using a serial printer; if the connector at the
- printer has 9 or 25 holes ["female"], then it's serial), say Y.
- Also read the Printing-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- It is possible to share one parallel port among several devices
- (e.g. printer and ZIP drive) and it is safe to compile the
- corresponding drivers into the kernel. If you want to compile this
- driver as a module however, choose M here and read
- <file:Documentation/parport.txt>. The module will be called lp.
-
- If you have several parallel ports, you can specify which ports to
- use with the "lp" kernel command line option. (Try "man bootparam"
- or see the documentation of your boot loader (silo) about how to pass
- options to the kernel at boot time.) The syntax of the "lp" command
- line option can be found in <file:drivers/char/lp.c>.
-
- If you have more than 8 printers, you need to increase the LP_NO
- macro in lp.c and the PARPORT_MAX macro in parport.h.
-
-source "mm/Kconfig"
-
-endmenu
-
-source "drivers/base/Kconfig"
-
-source "drivers/video/Kconfig"
-
-source "drivers/mtd/Kconfig"
-
-source "drivers/serial/Kconfig"
-
if !SUN4
source "drivers/sbus/char/Kconfig"
endif
-source "drivers/block/Kconfig"
-
-# Don't frighten a common SBus user
-if PCI
-
-source "drivers/ide/Kconfig"
-
-endif
-
-source "drivers/isdn/Kconfig"
-
-source "drivers/scsi/Kconfig"
-
-source "drivers/fc4/Kconfig"
-
-source "drivers/md/Kconfig"
-
-source "net/Kconfig"
-
# This one must be before the filesystem configs. -DaveM
menu "Unix98 PTY support"
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: 2.6.12-mm2
[not found] <fa.h6rvsi4.j68fhk@ifi.uio.no>
@ 2005-06-27 6:44 ` Reuben Farrelly
2005-06-27 7:24 ` 2.6.12-mm2 Andrew Morton
0 siblings, 1 reply; 57+ messages in thread
From: Reuben Farrelly @ 2005-06-27 6:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hi,
On 26/06/2005 11:12 a.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm2/
>
>
> - A reminder that there is a vger mailing list for tracking patches which
> are added to -mm. Do
>
> `echo subscribe mm-commits | mail majordomo@vger.kernel.org'
>
> - Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get
> the recent PCI breakage sorted out.
>
> - Big arch/cris update.
Some bad stuff seems to be happening here (this is new to -mm2; -mm1 did not
have this problem).
It's 100% reproduceable, although seems to happen at slightly different places
in the bootup, especially at the end. Did I miss a patch for this?
reuben
Linux version 2.6.12-mm2 (root@tornado) (gcc version 4.0.0 20050622 (Red Hat
4.0.0-13)) #1 SMP Mon Jun 27 01:19:41 NZST 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000f52e0
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:3 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:3 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 20000000 (gap: 20000000:dec00000)
Built 1 zonelists
Initializing CPU#0
Kernel command line: ro root=/dev/md2 console=ttyS1,57600
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 2813.906 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 515240k/524224k available (2133k kernel code, 8504k reserved, 920k
data, 204k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 5635.43 BogoMIPS (lpj=11270866)
Mount-cache hash table entries: 512
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03
Booting processor 1/1 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 5627.52 BogoMIPS (lpj=11255052)
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03
Total of 2 processors activated (11262.95 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
softlockup thread 0 started up.
Brought up 2 CPUs
softlockup thread 1 started up.
-> [0][1][ 524288] 0.0 [ 0.0] (0): ( 30446 15223)
-> [0][1][ 551882] 0.0 [ 0.0] (0): ( 12568 16550)
-> [0][1][ 580928] 0.0 [ 0.0] (0): ( -2456 15787)
-> [0][1][ 611503] 0.0 [ 0.0] (0): ( -4468 8899)
-> [0][1][ 643687] 0.0 [ 0.0] (0): ( -10064 7247)
-> [0][1][ 677565] 0.0 [ 0.0] (0): ( 6817 12064)
-> [0][1][ 713226] 0.0 [ 0.0] (0): ( 15269 10258)
-> [0][1][ 750764] 0.0 [ 0.0] (0): ( 16819 5904)
-> found max.
[0][1] working set size found: 524288, cost: 30446
---------------------
| migration cost matrix (max_cache_size: 1048576, cpu: 2813 MHz):
---------------------
[00] [01]
[00]: - 0.0(0)
[01]: 0.0(0) -
--------------------------------
| cacheflush times [1]: 0.0 (60892)
| calibration delay: 0 seconds
--------------------------------
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb440, last bus=3
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
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)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,disabled.
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
Machine check exception polling timer started.
inotify device minor=63
Initializing Cryptographic API
Real Time Clock Driver v1.12
hw_random: RNG not detected
Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60
seconds).
Hangcheck: Using monotonic_clock().
cn_fork is registered
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
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[<c0103ad0>] dump_stack+0x17/0x19
[<c01cab4b>] spin_bug+0x5b/0x67
[<c01cac9c>] _raw_spin_lock+0x78/0x7a
[<c0314ad9>] _spin_lock+0x8/0xa
[<c0313370>] schedule+0x6c0/0xd68
[<c0100d31>] cpu_idle+0x64/0x66
[<c01002c5>] rest_init+0x25/0x27
[<c03fe8af>] start_kernel+0x154/0x167
[<c010020f>] 0xc010020f
Kernel panic - not syncing: bad locking
Badness in smp_call_function at arch/i386/kernel/smp.c:553
[<c0103ad0>] dump_stack+0x17/0x19
[<c010f980>] smp_call_function+0x137/0x13c
[<c010fb49>] smp_send_stop+0x1e/0x27
[<c011c2cf>] panic+0x4c/0x102
[<c01cab57>] __spin_lock_debug+0x0/0xcd
[<c01cac9c>] _raw_spin_lock+0x78/0x7a
[<c0314ad9>] _spin_lock+0x8/0xa
[<c0313370>] schedule+0x6c0/0xd68
[<c0100d31>] cpu_idle+0x64/0x66
[<c01002c5>] rest_init+0x25/0x27
[<c03fe8af>] start_kernel+0x154/0x167
[<c010020f>] 0xc010020f
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: 2.6.12-mm2
2005-06-27 6:44 ` 2.6.12-mm2 Reuben Farrelly
@ 2005-06-27 7:24 ` Andrew Morton
2005-06-27 7:47 ` 2.6.12-mm2 Reuben Farrelly
0 siblings, 1 reply; 57+ messages in thread
From: Andrew Morton @ 2005-06-27 7:24 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: linux-kernel, Ingo Molnar
Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
> ...
>
> Some bad stuff seems to be happening here (this is new to -mm2; -mm1 did not
> have this problem).
>
> It's 100% reproduceable, although seems to happen at slightly different places
> in the bootup, especially at the end. Did I miss a patch for this?
>
Why do you keep breaking my kernel?
> ...
> Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
> ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [<c0103ad0>] dump_stack+0x17/0x19
> [<c01cab4b>] spin_bug+0x5b/0x67
> [<c01cac9c>] _raw_spin_lock+0x78/0x7a
> [<c0314ad9>] _spin_lock+0x8/0xa
> [<c0313370>] schedule+0x6c0/0xd68
> [<c0100d31>] cpu_idle+0x64/0x66
> [<c01002c5>] rest_init+0x25/0x27
> [<c03fe8af>] start_kernel+0x154/0x167
> [<c010020f>] 0xc010020f
> Kernel panic - not syncing: bad locking
That's odd - we lost a printk there:
printk("BUG: spinlock %s on CPU#%d, %s/%d, %p\n", msg,
smp_processor_id(), current->comm, current->pid, lock);
which is a shame, because it would have told us stuff. Do you have any
traces which do have that message?
Anyway, scary trace. It look like some spinlock is thought to be in the
wrong state in schedule(). Send the .config, please.
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: 2.6.12-mm2
2005-06-27 7:24 ` 2.6.12-mm2 Andrew Morton
@ 2005-06-27 7:47 ` Reuben Farrelly
2005-06-27 8:22 ` 2.6.12-mm2 Andrew Morton
0 siblings, 1 reply; 57+ messages in thread
From: Reuben Farrelly @ 2005-06-27 7:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Ingo Molnar
Hi,
On 27/06/2005 7:24 p.m., Andrew Morton wrote:
> Reuben Farrelly <reuben-lkml@reub.net> wrote:
>> ...
>>
>> Some bad stuff seems to be happening here (this is new to -mm2; -mm1 did not
>> have this problem).
>>
>> It's 100% reproduceable, although seems to happen at slightly different places
>> in the bootup, especially at the end. Did I miss a patch for this?
>>
>
> Why do you keep breaking my kernel?
Sadistic enjoyment ;-)
>> Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
>> ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>> ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>> [<c0103ad0>] dump_stack+0x17/0x19
>> [<c01cab4b>] spin_bug+0x5b/0x67
>> [<c01cac9c>] _raw_spin_lock+0x78/0x7a
>> [<c0314ad9>] _spin_lock+0x8/0xa
>> [<c0313370>] schedule+0x6c0/0xd68
>> [<c0100d31>] cpu_idle+0x64/0x66
>> [<c01002c5>] rest_init+0x25/0x27
>> [<c03fe8af>] start_kernel+0x154/0x167
>> [<c010020f>] 0xc010020f
>> Kernel panic - not syncing: bad locking
>
> That's odd - we lost a printk there:
>
> printk("BUG: spinlock %s on CPU#%d, %s/%d, %p\n", msg,
> smp_processor_id(), current->comm, current->pid, lock);
>
> which is a shame, because it would have told us stuff. Do you have any
> traces which do have that message?
Uh. Likely got munged within hyperterm.
Here's a better one just created using QVT:
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
usb 3-1: new full speed USB device using uhci_hcd and address 2
hub 3-1:1.0: USB hub found
hub 3-1:1.0: 4 ports detected
usbcore: registered new driver hiddev
usb 4-1: new full speed USB device using uhci_hcd and address 2
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0
proto 2 vid 0x03F0 pid 0x6204
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.01:USB HID core driver
mice: PS/2 mouse device common for all mice
input: PC Speaker
md: raid1 personality registered as nr 3
md: md driver 0.90.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.38
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 24Kbytes
TCP established hash table entries: 32768 (order: 7, 786432 bytes)
TCP bind hash table entries: 32768 (order: 7, 655360 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP reno registered
GRE over IPv4 tunneling driver
ip_conntrack version 2.1 (4095 buckets, 32760 max) - 212 bytes per conntrack
usb 3-1.1: new low speed USB device using uhci_hcd and address 3
BUG: spinlock recursion on CPU#0, swapper/0, c1407160
[<c0103ad0>] dump_stack+0x17/0x19
[<c01cab4b>] spin_bug+0x5b/0x67
[<c01cac9c>] _raw_spin_lock+0x78/0x7a
[<c0314ad9>] _spin_lock+0x8/0xa
[<c0117399>] scheduler_tick+0xd0/0x37c
[<c01256b3>] update_process_times+0x58/0xd7
[<c0110f50>] smp_apic_timer_interrupt+0xde/0xe0
[<c0103614>] apic_timer_interrupt+0x1c/0x24
[<c0100d1e>] cpu_idle+0x51/0x66
[<c01002c5>] rest_init+0x25/0x27
[<c03fe8af>] start_kernel+0x154/0x167
[<c010020f>] 0xc010020f
Kernel panic - not syncing: bad locking
Badness in smp_call_function at arch/i386/kernel/smp.c:553
[<c0103ad0>] dump_stack+0x17/0x19
[<c010f980>] smp_call_function+0x137/0x13c
[<c010fb49>] smp_send_stop+0x1e/0x27
[<c011c2cf>] panic+0x4c/0x102
[<c01cab57>] __spin_lock_debug+0x0/0xcd
[<c01cac9c>] _raw_spin_lock+0x78/0x7a
[<c0314ad9>] _spin_lock+0x8/0xa
[<c0117399>] scheduler_tick+0xd0/0x37c
[<c01256b3>] update_process_times+0x58/0xd7
[<c0110f50>] smp_apic_timer_interrupt+0xde/0xe0
[<c0103614>] apic_timer_interrupt+0x1c/0x24
[<c0100d1e>] cpu_idle+0x51/0x66
[<c01002c5>] rest_init+0x25/0x27
[<c03fe8af>] start_kernel+0x154/0x167
[<c010020f>] 0xc010020f
> Anyway, scary trace. It look like some spinlock is thought to be in the
> wrong state in schedule(). Send the .config, please.
Now online at http://www.reub.net/kernel/.config
Reuben
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: 2.6.12-mm2
2005-06-27 7:47 ` 2.6.12-mm2 Reuben Farrelly
@ 2005-06-27 8:22 ` Andrew Morton
2005-06-27 9:37 ` 2.6.12-mm2 Ingo Molnar
0 siblings, 1 reply; 57+ messages in thread
From: Andrew Morton @ 2005-06-27 8:22 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: linux-kernel, mingo
Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
> > Anyway, scary trace. It look like some spinlock is thought to be in the
> > wrong state in schedule(). Send the .config, please.
>
> Now online at http://www.reub.net/kernel/.config
Me too.
BUG: spinlock recursion on CPU#0, swapper/0, c120d520
[<c01039ed>] dump_stack+0x19/0x20
[<c01d9af2>] spin_bug+0x42/0x54
[<c01d9bfa>] _raw_spin_lock+0x3e/0x84
[<c031d0ad>] _spin_lock+0x9/0x10
[<c031b9e9>] schedule+0x479/0xbc8
[<c0100cb4>] cpu_idle+0x88/0x8c
[<c01002c1>] rest_init+0x21/0x28
[<c0442899>] start_kernel+0x151/0x158
[<c010020f>] 0xc010020f
Kernel panic - not syncing: bad locking
The bug is in the new spinlock debugging code itself. Ingo, can you test
that .config please?
Reuben, I guess disabling CONFIG_DEBUG_SPINLOCK will get you going.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: 2.6.12-mm2
2005-06-27 8:22 ` 2.6.12-mm2 Andrew Morton
@ 2005-06-27 9:37 ` Ingo Molnar
2005-06-27 21:14 ` 2.6.12-mm2 Andrew Morton
0 siblings, 1 reply; 57+ messages in thread
From: Ingo Molnar @ 2005-06-27 9:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: Reuben Farrelly, linux-kernel
is the fput()/sysfs_release() crash below known?
Ingo
Linux version 2.6.12-mm2 (mingo@jupiter) (gcc version 3.4.1 20040831 (Red Hat 3.4.1-10)) #11 SMP Mon Jun 27 11:19:41 CEST 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
256MB LOWMEM available.
found SMP MP-table at 000f5b30
On node 0 totalpages: 65536
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 61440 pages, LIFO batch:31
HighMem zone: 0 pages, LIFO batch:1
early console enabled
DMI 2.2 present.
ABIT i440BX-W83977 detected: force use of acpi=ht
ACPI: Unable to locate RSDP
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 6:6 APIC version 17
Processor #1 6:6 APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 2
Allocating PCI resources starting at 10000000 (gap: 10000000:eec00000)
Built 1 zonelists
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
Kernel command line: root=/dev/hda1 debug earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 console=tty0 3 maxcpus=2 nmi_watchdog=1 debug profile=0
kernel profiling enabled (shift: 0)
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 467.796 MHz processor.
Using tsc for high-res timesource
disabling early console
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 244664k/262144k available (2592k kernel code, 17052k reserved, 1061k data, 224k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 937.21 BogoMIPS (lpj=1874423)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0183fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0183fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU: After all inits, caps: 0183fbff 00000000 00000000 00000040 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
CPU0: Intel Celeron (Mendocino) stepping 05
Booting processor 1/1 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 935.62 BogoMIPS (lpj=1871246)
CPU: After generic identify, caps: 0183fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0183fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU: After all inits, caps: 0183fbff 00000000 00000000 00000040 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Celeron (Mendocino) stepping 05
Total of 2 processors activated (1872.83 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
checking TSC synchronization across 2 CPUs: passed.
softlockup thread 0 started up.
Brought up 2 CPUs
softlockup thread 1 started up.
-> [0][1][ 65536] 0.3 [ 0.3] (0): ( 357620 178810)
-> [0][1][ 68985] 0.3 [ 0.3] (0): ( 354253 91088)
-> [0][1][ 72615] 0.3 [ 0.3] (0): ( 390935 63885)
-> [0][1][ 76436] 0.4 [ 0.4] (0): ( 415617 44283)
-> [0][1][ 80458] 0.4 [ 0.4] (0): ( 428850 28758)
-> [0][1][ 84692] 0.4 [ 0.4] (0): ( 460558 30233)
-> [0][1][ 89149] 0.5 [ 0.5] (0): ( 501929 35802)
-> [0][1][ 93841] 0.5 [ 0.5] (0): ( 543036 38454)
-> [0][1][ 98780] 0.6 [ 0.6] (0): ( 609270 52344)
-> [0][1][ 103978] 0.5 [ 0.6] (0): ( 596005 32804)
-> [0][1][ 109450] 0.6 [ 0.6] (0): ( 607209 22004)
-> [0][1][ 115210] 0.6 [ 0.6] (0): ( 643212 29003)
-> [0][1][ 121273] 0.7 [ 0.7] (0): ( 716535 51163)
-> [0][1][ 127655] 0.7 [ 0.7] (0): ( 795865 65246)
-> [0][1][ 134373] 0.7 [ 0.7] (0): ( 745335 57888)
-> [0][1][ 141445] 0.7 [ 0.7] (0): ( 796304 54428)
-> [0][1][ 148889] 0.8 [ 0.8] (0): ( 820203 39163)
-> [0][1][ 156725] 0.7 [ 0.8] (0): ( 716504 71431)
-> [0][1][ 164973] 0.6 [ 0.8] (0): ( 679884 54025)
-> [0][1][ 173655] 0.6 [ 0.8] (0): ( 662305 35802)
-> [0][1][ 182794] 0.5 [ 0.8] (0): ( 598857 49625)
-> [0][1][ 192414] 0.6 [ 0.8] (0): ( 628063 39415)
-> [0][1][ 202541] 0.5 [ 0.8] (0): ( 577476 45001)
-> found max.
[0][1] working set size found: 148889, cost: 820203
---------------------
| migration cost matrix (max_cache_size: 131072, cpu: 467 MHz):
---------------------
[00] [01]
[00]: - 1.6(0)
[01]: 1.6(0) -
--------------------------------
| cacheflush times [1]: 1.6 (1640406)
| calibration delay: 0 seconds
--------------------------------
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb420, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs.
mtrr: corrected configuration.
ACPI: Subsystem revision 20050309
ACPI: Interpreter disabled.
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:01:00.0
PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:07.0
PCI->APIC IRQ transform: 0000:00:07.2[D] -> IRQ 19
PCI->APIC IRQ transform: 0000:00:0b.0[A] -> IRQ 18
PCI->APIC IRQ transform: 0000:00:0d.0[A] -> IRQ 17
PCI->APIC IRQ transform: 0000:00:0f.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:00:13.0[A] -> IRQ 18
PCI->APIC IRQ transform: 0000:00:13.1[B] -> IRQ 18
PCI->APIC IRQ transform: 0000:01:00.0[A] -> IRQ 16
Machine check exception polling timer started.
inotify device minor=63
Initializing Cryptographic API
Limiting direct PCI/PCI transfers.
Real Time Clock Driver v1.12
Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
Hangcheck: Using monotonic_clock().
cn_fork is registered
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
ÿttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
Intel(R) PRO/1000 Network Driver - version 6.0.54-k2-NAPI
Copyright (c) 1999-2004 Intel Corporation.
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
e100: eth1: e100_probe: addr 0xef140000, irq 16, MAC addr 00:90:27:8C:A0:50
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot 0000:00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: QUANTUM FIREBALLP LM20.5, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: QUANTUM FIREBALL SE4.3A, ATA DISK drive
hdd: LG CD-ROM CRD-8522B, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 40132503 sectors (20547 MB) w/1900KiB Cache, CHS=39813/16/63, UDMA(33)
hda: cache flushes not supported
hda: hda1
hdc: max request size: 128KiB
hdc: 8418816 sectors (4310 MB) w/80KiB Cache, CHS=14848/9/63, UDMA(33)
hdc: cache flushes not supported
hdc: hdc1 hdc2
libata version 1.11 loaded.
USB Universal Host Controller Interface driver v2.3
uhci_hcd 0000:00:07.2: Intel Corporation 82371AB/EB/MB PIIX4 USB
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:07.2: irq 19, io base 0x0000b000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.01:USB HID core driver
mice: PS/2 mouse device common for all mice
input: PC Speaker
md: raid1 personality registered as nr 3
md: md driver 0.90.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.38
NET: Registered protocol family 2
input: AT Translated Set 2 keyboard on isa0060/serio0
IP: routing cache hash table of 512 buckets, 12Kbytes
TCP established hash table entries: 16384 (order: 6, 393216 bytes)
TCP bind hash table entries: 16384 (order: 6, 327680 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
GRE over IPv4 tunneling driver
ip_conntrack version 2.1 (2048 buckets, 16384 max) - 212 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
NET: Registered protocol family 1
NET: Registered protocol family 17
Testing NMI watchdog ... OK.
Starting balanced_irq
Using IPI Shortcut mode
BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 224k freed
Unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip:
c018b51c
*pde = 00000000
Oops: 0002 [#1]
SMP
Modules linked in:
CPU: 1
EIP: 0060:[<c018b51c>] Not tainted VLI
EFLAGS: 00010206 (2.6.12-mm2)
EIP is at sysfs_release+0x3f/0x79
eax: 6b6b6beb ebx: 6b6b6b6b ecx: ce5b5e64 edx: 00000000
esi: cf266ca4 edi: cfa3a544 ebp: ce635f50 esp: ce635f44
ds: 007b es: 007b ss: 0068
Process udev (pid: 1286, threadinfo=ce634000 task=c1fe6040)
Stack: 00000010 c1ca8b78 c1d4656c ce635f74 c01580b2 00000000 cf399e10 cf399e10
ce5b5e64 c1d4656c c1cb275c 00000000 ce635f84 c0157f36 c1cb275c c1d4656c
ce635f9c c0156873 00000004 00000004 c1cb275c c1cb2760 ce635fb4 c015690a
Call Trace:
[<c0103a18>] show_stack+0x7c/0x92
[<c0103b99>] show_registers+0x152/0x1ca
[<c0103d96>] die+0xf4/0x16f
[<c011433f>] do_page_fault+0x466/0x684
[<c0103683>] error_code+0x4f/0x54
[<c01580b2>] __fput+0x176/0x1a9
[<c0157f36>] fput+0x3b/0x41
[<c0156873>] filp_close+0x36/0x65
[<c015690a>] sys_close+0x68/0x83
[<c0102b13>] sysenter_past_esp+0x54/0x75
Code: 58 8b 70 14 8b 41 58 8b 40 14 85 f6 8b 58 04 74 07 89 f0 e8 8b 22 05 00 85 db 74 1a b8 00 e0 ff ff 21 e0 8b 40 10 c1 e0 07 01 d8 <ff> 88 00 01 00 00 83 3b 02 74 22 85 ff 74 0e 8b 47 0c 85 c0 75
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: 2.6.12-mm2
2005-06-27 9:37 ` 2.6.12-mm2 Ingo Molnar
@ 2005-06-27 21:14 ` Andrew Morton
2005-06-28 7:30 ` 2.6.12-mm2 Ingo Molnar
0 siblings, 1 reply; 57+ messages in thread
From: Andrew Morton @ 2005-06-27 21:14 UTC (permalink / raw)
To: Ingo Molnar; +Cc: reuben-lkml, linux-kernel
Ingo Molnar <mingo@elte.hu> wrote:
>
> is the fput()/sysfs_release() crash below known?
It doesn't ring any bells.
You have a use-after-free error when udev is dinking with a sysfs file. It
could be anything. Could you debug it a bit, please, work out which file
caused the crash?
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: 2.6.12-mm2
2005-06-27 21:14 ` 2.6.12-mm2 Andrew Morton
@ 2005-06-28 7:30 ` Ingo Molnar
0 siblings, 0 replies; 57+ messages in thread
From: Ingo Molnar @ 2005-06-28 7:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: reuben-lkml, linux-kernel
* Andrew Morton <akpm@osdl.org> wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
> >
> > is the fput()/sysfs_release() crash below known?
>
> It doesn't ring any bells.
>
> You have a use-after-free error when udev is dinking with a sysfs
> file. It could be anything. Could you debug it a bit, please, work
> out which file caused the crash?
unfortunately it's totally unreproducible, it triggered only once during
hundreds of bootups. Will keep eyes open though.
Ingo
^ permalink raw reply [flat|nested] 57+ messages in thread