* 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ 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; 50+ 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] 50+ messages in thread