Re: ide: Use of_node_name_eq for node name comparisons

[Michael Ellerman]

On Wed, 2018-12-05 at 19:50:25 UTC, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
> 
> Cc: "David S. Miller" 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linux-...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/c1fa31b0fc90a80d64a334e5d35dca

cheers

Re: ide: pmac: Convert to using %pOF instead of full_name

[Michael Ellerman]

On Tue, 2017-07-18 at 21:43:07 UTC, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: "David S. Miller" 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linux-...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Acked-by: David S. Miller 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/859420e3155d8192b31a93cd92d32c

cheers

Re: IDE cable detection on Apple PowerBook

[Benjamin Herrenschmidt]

On Thu, 2009-03-19 at 22:30 +0900, TOMARI Hisanobu wrote:
 Thanks for helpful advices.
 This patch adds an option to drivers/ide/Kconfig and adds 
 some lines to drivers/ide/pmac.c . Now the driver checks
 if the model is prefixed with PowerBook and the entire hack
 can be toggled in the Kconfig.
 
 Again, the patch is against linux 2.6.28.8.

Ack. I forwarded it to Bart for his queue.

Ben.

 Best regards,
 TOMARI Hisanobu
 
 p.s. oddly, the drive works in ATA/100 mode under untouched
 MacOS X 10.5.
 
 On Thu, 19 Mar 2009 17:08:37 +1100
 Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
 
  On Thu, 2009-03-19 at 17:07 +1100, Benjamin Herrenschmidt wrote:
   On Wed, 2009-03-18 at 22:47 +0900, TOMARI Hisanobu wrote:
I thought the short-40pin assumption would cause no problem
considering all models beginning with PowerBook5 are laptops.
Do you mean an option to toggle this hack on/off should be present 
in Kconfig?
   
   Actually, it makes -some- amount of sense to do it by testing
   specifically for the prefix PowerBook and iBook without a specific
   number I suppose.
  
  Actually PowerBook is enough, there's no iBook prefix in the
  device-tree, I was confusing with old busted iMac firmwares that used
  iMac instead of PowerMac in there.
  
  Cheers,
  Ben.
  
   Ben.
   
Thanks,
TOMARI Hisanobu

On Wed, 18 Mar 2009 18:58:17 +1100
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:

 On Wed, 2009-03-18 at 14:06 +0900, TOMARI Hisanobu wrote:
  Hello,
  
  I'm using an OCZ PATA SSD on Apple PowerBook5,4 computer.
  The IDE drive fails to recognize 80-conductor cable that
  connects the drive to motherboard to fall back to UDMA33.
  
  This patch fixes this behavior by assuming that the cable is
  short-40pin when the model string matches PowerBook5 and 
  the motherboard detects 80c cable.
  
  This patch is against drivers/ide/pmac.c in linux 2.6.28.8.
 
 The patch is too much of an ad-hoc hack... _maybe_ an option is to 
 make
 the core fallback to 40 short when 80 pin detection fails on
 powerbooks instead ?
 
 Ben.
 
  (before applying the patch) hdparm -i /dev/hda
  /dev/hda:
   Timing buffered disk reads:   90 MB in  3.03 seconds =  29.73 
  MB/sec
  (dmesg 2.6.26)
  ide0: Found Apple UniNorth ATA-6 controller, bus ID 3, irq 39
  Probing IDE interface ide0...
  hda: CORE_PATA, ATA DISK drive
  hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
  hda: drive side 80-wire cable detection failed, limiting max speed 
  to UDMA33
  hda: UDMA/33 mode selected
  
  (after applying the patch) hdparm -i /dev/hda
  /dev/hda:
   Timing buffered disk reads:  240 MB in  3.02 seconds =  79.42 
  MB/sec
  (dmesg 2.6.28.8)
  ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID 3, 
  irq 39
  Probing IDE interface ide0...
  hda: CORE_PATA, ATA DISK drive
  hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
  hda: UDMA/100 mode selected
  ide0 at 0xf102a000-0xf102a070,0xf102a160 on irq 39
  
  
  ___
  Linuxppc-dev mailing list
  Linuxppc-dev@ozlabs.org
  https://ozlabs.org/mailman/listinfo/linuxppc-dev
 
  

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [Fwd: Re: IDE cable detection on Apple PowerBook]

[TOMARI Hisanobu]

On Fri, 20 Mar 2009 12:40:29 +0100
Bartlomiej Zolnierkiewicz bzoln...@gmail.com wrote:

 Moreover the underlying issue is non-PMAC specific and asks for generic
 resolution, please see:
 
   http://bugzilla.kernel.org/show_bug.cgi?id=12734#c13
 
 for previous discussion.
 
 In the very least case it should be a generic kernel parameter, i.e.
 ide_core.ignore_cables and iff the current ide_core.ignore_cable=
 is not enough.  TOMARI, could please look into it?
 
 Thanks,
 Bart

It works!
As the internal IDE controller is detected as ide0, I passed
ide_core.ignore_cable=0 to the kernel, and the drive works in
UDMA/100 mode.
This method seems much cleaner way to solve the problem.
Thank you, Bart, Ben and Anton.

% dmesg |grep hda
Kernel command line: root=/dev/hda4 ro ide_core.ignore_cable=0 
hda: CORE_PATA, ATA DISK drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/100 mode selected
hda: max request size: 512KiB
hda: 252411904 sectors (129234 MB), CHS=16383/255/63
hda: cache flushes supported
 hda: [mac] hda1 hda2 hda3 hda4 hda5 hda6 hda7
XFS mounting filesystem hda4
Ending clean XFS mount for filesystem: hda4
Adding 846672k swap on /dev/hda5.  Priority:-1 extents:1 across:846672k

-- 
TOMARI Hisanobu posco.gr...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE cable detection on Apple PowerBook

[Benjamin Herrenschmidt]

On Wed, 2009-03-18 at 22:47 +0900, TOMARI Hisanobu wrote:
 I thought the short-40pin assumption would cause no problem
 considering all models beginning with PowerBook5 are laptops.
 Do you mean an option to toggle this hack on/off should be present 
 in Kconfig?

Actually, it makes -some- amount of sense to do it by testing
specifically for the prefix PowerBook and iBook without a specific
number I suppose.

Ben.

 Thanks,
 TOMARI Hisanobu
 
 On Wed, 18 Mar 2009 18:58:17 +1100
 Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
 
  On Wed, 2009-03-18 at 14:06 +0900, TOMARI Hisanobu wrote:
   Hello,
   
   I'm using an OCZ PATA SSD on Apple PowerBook5,4 computer.
   The IDE drive fails to recognize 80-conductor cable that
   connects the drive to motherboard to fall back to UDMA33.
   
   This patch fixes this behavior by assuming that the cable is
   short-40pin when the model string matches PowerBook5 and 
   the motherboard detects 80c cable.
   
   This patch is against drivers/ide/pmac.c in linux 2.6.28.8.
  
  The patch is too much of an ad-hoc hack... _maybe_ an option is to make
  the core fallback to 40 short when 80 pin detection fails on
  powerbooks instead ?
  
  Ben.
  
   (before applying the patch) hdparm -i /dev/hda
   /dev/hda:
Timing buffered disk reads:   90 MB in  3.03 seconds =  29.73 MB/sec
   (dmesg 2.6.26)
   ide0: Found Apple UniNorth ATA-6 controller, bus ID 3, irq 39
   Probing IDE interface ide0...
   hda: CORE_PATA, ATA DISK drive
   hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
   hda: drive side 80-wire cable detection failed, limiting max speed to 
   UDMA33
   hda: UDMA/33 mode selected
   
   (after applying the patch) hdparm -i /dev/hda
   /dev/hda:
Timing buffered disk reads:  240 MB in  3.02 seconds =  79.42 MB/sec
   (dmesg 2.6.28.8)
   ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID 3, irq 39
   Probing IDE interface ide0...
   hda: CORE_PATA, ATA DISK drive
   hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
   hda: UDMA/100 mode selected
   ide0 at 0xf102a000-0xf102a070,0xf102a160 on irq 39
   
   
   ___
   Linuxppc-dev mailing list
   Linuxppc-dev@ozlabs.org
   https://ozlabs.org/mailman/listinfo/linuxppc-dev
  

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE cable detection on Apple PowerBook

[Benjamin Herrenschmidt]

On Thu, 2009-03-19 at 17:07 +1100, Benjamin Herrenschmidt wrote:
 On Wed, 2009-03-18 at 22:47 +0900, TOMARI Hisanobu wrote:
  I thought the short-40pin assumption would cause no problem
  considering all models beginning with PowerBook5 are laptops.
  Do you mean an option to toggle this hack on/off should be present 
  in Kconfig?
 
 Actually, it makes -some- amount of sense to do it by testing
 specifically for the prefix PowerBook and iBook without a specific
 number I suppose.

Actually PowerBook is enough, there's no iBook prefix in the
device-tree, I was confusing with old busted iMac firmwares that used
iMac instead of PowerMac in there.

Cheers,
Ben.

 Ben.
 
  Thanks,
  TOMARI Hisanobu
  
  On Wed, 18 Mar 2009 18:58:17 +1100
  Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
  
   On Wed, 2009-03-18 at 14:06 +0900, TOMARI Hisanobu wrote:
Hello,

I'm using an OCZ PATA SSD on Apple PowerBook5,4 computer.
The IDE drive fails to recognize 80-conductor cable that
connects the drive to motherboard to fall back to UDMA33.

This patch fixes this behavior by assuming that the cable is
short-40pin when the model string matches PowerBook5 and 
the motherboard detects 80c cable.

This patch is against drivers/ide/pmac.c in linux 2.6.28.8.
   
   The patch is too much of an ad-hoc hack... _maybe_ an option is to make
   the core fallback to 40 short when 80 pin detection fails on
   powerbooks instead ?
   
   Ben.
   
(before applying the patch) hdparm -i /dev/hda
/dev/hda:
 Timing buffered disk reads:   90 MB in  3.03 seconds =  29.73 MB/sec
(dmesg 2.6.26)
ide0: Found Apple UniNorth ATA-6 controller, bus ID 3, irq 39
Probing IDE interface ide0...
hda: CORE_PATA, ATA DISK drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: drive side 80-wire cable detection failed, limiting max speed to 
UDMA33
hda: UDMA/33 mode selected

(after applying the patch) hdparm -i /dev/hda
/dev/hda:
 Timing buffered disk reads:  240 MB in  3.02 seconds =  79.42 MB/sec
(dmesg 2.6.28.8)
ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID 3, irq 39
Probing IDE interface ide0...
hda: CORE_PATA, ATA DISK drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/100 mode selected
ide0 at 0xf102a000-0xf102a070,0xf102a160 on irq 39


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
   

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE cable detection on Apple PowerBook

[TOMARI Hisanobu]

Thanks for helpful advices.
This patch adds an option to drivers/ide/Kconfig and adds 
some lines to drivers/ide/pmac.c . Now the driver checks
if the model is prefixed with PowerBook and the entire hack
can be toggled in the Kconfig.

Again, the patch is against linux 2.6.28.8.

Best regards,
TOMARI Hisanobu

p.s. oddly, the drive works in ATA/100 mode under untouched
MacOS X 10.5.

On Thu, 19 Mar 2009 17:08:37 +1100
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:

 On Thu, 2009-03-19 at 17:07 +1100, Benjamin Herrenschmidt wrote:
  On Wed, 2009-03-18 at 22:47 +0900, TOMARI Hisanobu wrote:
   I thought the short-40pin assumption would cause no problem
   considering all models beginning with PowerBook5 are laptops.
   Do you mean an option to toggle this hack on/off should be present 
   in Kconfig?
  
  Actually, it makes -some- amount of sense to do it by testing
  specifically for the prefix PowerBook and iBook without a specific
  number I suppose.
 
 Actually PowerBook is enough, there's no iBook prefix in the
 device-tree, I was confusing with old busted iMac firmwares that used
 iMac instead of PowerMac in there.
 
 Cheers,
 Ben.
 
  Ben.
  
   Thanks,
   TOMARI Hisanobu
   
   On Wed, 18 Mar 2009 18:58:17 +1100
   Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
   
On Wed, 2009-03-18 at 14:06 +0900, TOMARI Hisanobu wrote:
 Hello,
 
 I'm using an OCZ PATA SSD on Apple PowerBook5,4 computer.
 The IDE drive fails to recognize 80-conductor cable that
 connects the drive to motherboard to fall back to UDMA33.
 
 This patch fixes this behavior by assuming that the cable is
 short-40pin when the model string matches PowerBook5 and 
 the motherboard detects 80c cable.
 
 This patch is against drivers/ide/pmac.c in linux 2.6.28.8.

The patch is too much of an ad-hoc hack... _maybe_ an option is to make
the core fallback to 40 short when 80 pin detection fails on
powerbooks instead ?

Ben.

 (before applying the patch) hdparm -i /dev/hda
 /dev/hda:
  Timing buffered disk reads:   90 MB in  3.03 seconds =  29.73 MB/sec
 (dmesg 2.6.26)
 ide0: Found Apple UniNorth ATA-6 controller, bus ID 3, irq 39
 Probing IDE interface ide0...
 hda: CORE_PATA, ATA DISK drive
 hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
 hda: drive side 80-wire cable detection failed, limiting max speed to 
 UDMA33
 hda: UDMA/33 mode selected
 
 (after applying the patch) hdparm -i /dev/hda
 /dev/hda:
  Timing buffered disk reads:  240 MB in  3.02 seconds =  79.42 MB/sec
 (dmesg 2.6.28.8)
 ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID 3, irq 
 39
 Probing IDE interface ide0...
 hda: CORE_PATA, ATA DISK drive
 hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
 hda: UDMA/100 mode selected
 ide0 at 0xf102a000-0xf102a070,0xf102a160 on irq 39
 
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev

 
*** linux-2.6.28.8/drivers/ide/Kconfig.old	2009-03-19 21:30:24.594129124 +0900
--- linux-2.6.28.8/drivers/ide/Kconfig	2009-03-19 21:49:41.776996312 +0900
***
*** 691,696 
--- 691,706 
  	  CD-ROM on hda. This option changes this to more natural hda for
  	  hard disk and hdc for CD-ROM.
  
+ config BLK_DEV_IDE_PMAC_SHORTCABLE
+bool Assume short IDE cable on PowerBook/iBook
+depends on BLK_DEV_IDE_PMAC
+help
+  Some IDE drives fail to recognize 80-conductor IDE cable used in
+ 	 PowerBooks and the driver limits the transfer speed to ATA/33.
+ 	 With this option, the driver reports the 80-conductor cable to be 
+ 	 of 40 conductor short type on PowerBook/iBook, and enables to use
+ 	 ATA/100 on drives that support the transfer mode.
+ 
  config BLK_DEV_IDE_AU1XXX
 bool IDE for AMD Alchemy Au1200
 depends on SOC_AU1200
*** linux-2.6.28.8/drivers/ide/pmac.c.orig	2009-03-19 22:21:14.137849502 +0900
--- linux-2.6.28.8/drivers/ide/pmac.c	2009-03-19 22:16:44.612877441 +0900
***
*** 917,926 
  		(pmac_ide_hwif_t *)dev_get_drvdata(hwif-gendev.parent);
  	struct device_node *np = pmif-node;
  	const char *cable = of_get_property(np, cable-type, NULL);
  
  	/* Get cable type from device-tree. */
  	if (cable  !strncmp(cable, 80-, 3))
! 		return ATA_CBL_PATA80;
  
  	/*
  	 * G5's seem to have incorrect cable type in device-tree.
--- 917,938 
  		(pmac_ide_hwif_t *)dev_get_drvdata(hwif-gendev.parent);
  	struct device_node *np = pmif-node;
  	const char *cable = of_get_property(np, cable-type, NULL);
+ #ifdef CONFIG_BLK_DEV_IDE_PMAC_SHORTCABLE
+ 	struct device_node *root = of_find_node_by_path(/);
+ 	const char *model = of_get_property(root, model, NULL);
+ #endif
  
  	/* Get cable type from device-tree. */
  	if (cable  

Re: IDE cable detection on Apple PowerBook

[Anton Vorontsov]

On Thu, Mar 19, 2009 at 10:30:01PM +0900, TOMARI Hisanobu wrote:
 Thanks for helpful advices.
 This patch adds an option to drivers/ide/Kconfig and adds 
 some lines to drivers/ide/pmac.c .

I think it would be better to make it a kernel command line option
instead of Kconfig knob.

The reason is: with distro (pre-compiled) kernels you don't have to
re-compile anything to make the drive work.

The other option is to enable BLK_DEV_IDE_PMAC_SHORTCABLE by default,
but I'm not sure if it's safe thing to do (most probably not).

Thanks for you work on this,

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE cable detection on Apple PowerBook

[Benjamin Herrenschmidt]

On Thu, 2009-03-19 at 16:41 +0300, Anton Vorontsov wrote:
 
 The other option is to enable BLK_DEV_IDE_PMAC_SHORTCABLE by default,
 but I'm not sure if it's safe thing to do (most probably not).

It should be allright for powerbooks. If the firmware says 80 pin cable,
then it probably is, and in fact, It used to work, I think the test in
the IDE code is new there, and MacOS X solely relies on the firmware
data.

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE cable detection on Apple PowerBook

[Benjamin Herrenschmidt]

On Wed, 2009-03-18 at 14:06 +0900, TOMARI Hisanobu wrote:
 Hello,
 
 I'm using an OCZ PATA SSD on Apple PowerBook5,4 computer.
 The IDE drive fails to recognize 80-conductor cable that
 connects the drive to motherboard to fall back to UDMA33.
 
 This patch fixes this behavior by assuming that the cable is
 short-40pin when the model string matches PowerBook5 and 
 the motherboard detects 80c cable.
 
 This patch is against drivers/ide/pmac.c in linux 2.6.28.8.

The patch is too much of an ad-hoc hack... _maybe_ an option is to make
the core fallback to 40 short when 80 pin detection fails on
powerbooks instead ?

Ben.

 (before applying the patch) hdparm -i /dev/hda
 /dev/hda:
  Timing buffered disk reads:   90 MB in  3.03 seconds =  29.73 MB/sec
 (dmesg 2.6.26)
 ide0: Found Apple UniNorth ATA-6 controller, bus ID 3, irq 39
 Probing IDE interface ide0...
 hda: CORE_PATA, ATA DISK drive
 hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
 hda: drive side 80-wire cable detection failed, limiting max speed to UDMA33
 hda: UDMA/33 mode selected
 
 (after applying the patch) hdparm -i /dev/hda
 /dev/hda:
  Timing buffered disk reads:  240 MB in  3.02 seconds =  79.42 MB/sec
 (dmesg 2.6.28.8)
 ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID 3, irq 39
 Probing IDE interface ide0...
 hda: CORE_PATA, ATA DISK drive
 hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
 hda: UDMA/100 mode selected
 ide0 at 0xf102a000-0xf102a070,0xf102a160 on irq 39
 
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE cable detection on Apple PowerBook

[TOMARI Hisanobu]

I thought the short-40pin assumption would cause no problem
considering all models beginning with PowerBook5 are laptops.
Do you mean an option to toggle this hack on/off should be present 
in Kconfig?

Thanks,
TOMARI Hisanobu

On Wed, 18 Mar 2009 18:58:17 +1100
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:

 On Wed, 2009-03-18 at 14:06 +0900, TOMARI Hisanobu wrote:
  Hello,
  
  I'm using an OCZ PATA SSD on Apple PowerBook5,4 computer.
  The IDE drive fails to recognize 80-conductor cable that
  connects the drive to motherboard to fall back to UDMA33.
  
  This patch fixes this behavior by assuming that the cable is
  short-40pin when the model string matches PowerBook5 and 
  the motherboard detects 80c cable.
  
  This patch is against drivers/ide/pmac.c in linux 2.6.28.8.
 
 The patch is too much of an ad-hoc hack... _maybe_ an option is to make
 the core fallback to 40 short when 80 pin detection fails on
 powerbooks instead ?
 
 Ben.
 
  (before applying the patch) hdparm -i /dev/hda
  /dev/hda:
   Timing buffered disk reads:   90 MB in  3.03 seconds =  29.73 MB/sec
  (dmesg 2.6.26)
  ide0: Found Apple UniNorth ATA-6 controller, bus ID 3, irq 39
  Probing IDE interface ide0...
  hda: CORE_PATA, ATA DISK drive
  hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
  hda: drive side 80-wire cable detection failed, limiting max speed to UDMA33
  hda: UDMA/33 mode selected
  
  (after applying the patch) hdparm -i /dev/hda
  /dev/hda:
   Timing buffered disk reads:  240 MB in  3.02 seconds =  79.42 MB/sec
  (dmesg 2.6.28.8)
  ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID 3, irq 39
  Probing IDE interface ide0...
  hda: CORE_PATA, ATA DISK drive
  hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
  hda: UDMA/100 mode selected
  ide0 at 0xf102a000-0xf102a070,0xf102a160 on irq 39
  
  
  ___
  Linuxppc-dev mailing list
  Linuxppc-dev@ozlabs.org
  https://ozlabs.org/mailman/listinfo/linuxppc-dev
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Sébastien Chrétien]

Where can I find a pata_of_platform node example ?

Sergei Shtylyov a écrit :

Arnd Bergmann wrote:

  Most probably you can use the existing platform drivers: 
drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c.
Create/register a platform device named pata_platform with 2 
memory and 1 IRQ resource, and enable one of those drivers.



For new boards using a flattened device tree, it should be enough
to add a device node for the pata_of_platform driver.


   Oops, forgot about this one. No wonder, after being knee deep in 
ARM for several months. :-)


MBR, Sergei


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Sébastien Chrétien]

I saw pata_of_platform source. And when is called pata_of_platform_probe ?

2008/9/11, Sébastien Chrétien [EMAIL PROTECTED]:

 Where can I find a pata_of_platform node example ?

 Sergei Shtylyov a écrit :

 Arnd Bergmann wrote:

   Most probably you can use the existing platform drivers:
 drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c.
 Create/register a platform device named pata_platform with 2 memory
 and 1 IRQ resource, and enable one of those drivers.


  For new boards using a flattened device tree, it should be enough
 to add a device node for the pata_of_platform driver.


   Oops, forgot about this one. No wonder, after being knee deep in ARM for
 several months. :-)

 MBR, Sergei


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Sergei Shtylyov]

Hello.

Sébastien Chrétien wrote:


I saw pata_of_platform source. And when is called pata_of_platform_probe ?


  Look at the very end of arch/powerpc/boot/dts/mpc8349emitx.dts; 
probably there are more examples in that directory...


MBR, Sergei


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Sergei Shtylyov]

Hello.

Sébastien Chrétien wrote:

I would like to setup my IDE controller. It uses a generic mapping. 
And he is located at the adress 0x20003000.


  What kin of controller, and what do you mean by generic mapping?


How can I specifie this adress to the ide driver ?


  The usual ways is via the platform device.


MBR, Sergei


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Sébastien Chrétien]

Have I to rewrite a IDE driver ?

2008/9/10, Sergei Shtylyov [EMAIL PROTECTED]:

 Hello.

 Sébastien Chrétien wrote:

  I would like to setup my IDE controller. It uses a generic mapping. And he
 is located at the adress 0x20003000.


  What kin of controller, and what do you mean by generic mapping?

  How can I specifie this adress to the ide driver ?


  The usual ways is via the platform device.


 MBR, Sergei



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Sébastien Chrétien]

It is a common ide controller :
offset 0x0 Data
offset 0x1 error
offset 0x2 Sector count
offset 0x3 sector No
offset 0x4 Cylinder low
offset 0x5 Cylinder High
offset 0x6 Head
offset 0x7 status

2008/9/10, Sergei Shtylyov [EMAIL PROTECTED]:

 Hello.

 Sébastien Chrétien wrote:

  I would like to setup my IDE controller. It uses a generic mapping. And he
 is located at the adress 0x20003000.


  What kin of controller, and what do you mean by generic mapping?

  How can I specifie this adress to the ide driver ?


  The usual ways is via the platform device.


 MBR, Sergei



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Sergei Shtylyov]

Hello.

Sébastien Chrétien wrote:


Have I to rewrite a IDE driver ?


  Most probably you can use the existing platform drivers: 
drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c.
Create/register a platform device named pata_platform with 2 memory 
and 1 IRQ resource, and enable one of those drivers.


2008/9/10, Sergei Shtylyov [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]:


Hello.

Sébastien Chrétien wrote:

I would like to setup my IDE controller. It uses a generic
mapping. And he is located at the adress 0x20003000.


 What kin of controller, and what do you mean by generic mapping?

How can I specifie this adress to the ide driver ?


 The usual ways is via the platform device.




MBR, Sergei


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Arnd Bergmann]

On Wednesday 10 September 2008, Sergei Shtylyov wrote:
    Most probably you can use the existing platform drivers: 
 drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c.
 Create/register a platform device named pata_platform with 2 memory 
 and 1 IRQ resource, and enable one of those drivers.

For new boards using a flattened device tree, it should be enough
to add a device node for the pata_of_platform driver.
If you need a device specific setup, you should add a new compatible
value in the tree and make the driver handle that in whatever
way you need.

Arnd 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Sébastien Chrétien]

I looked falconide.c, it uses hw_regs_t hw; and ide_hwif_t *hwif.
Is it a good way ?

2008/9/10, Arnd Bergmann [EMAIL PROTECTED]:

 On Wednesday 10 September 2008, Sergei Shtylyov wrote:
 Most probably you can use the existing platform drivers:
  drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c.
  Create/register a platform device named pata_platform with 2 memory
  and 1 IRQ resource, and enable one of those drivers.


 For new boards using a flattened device tree, it should be enough
 to add a device node for the pata_of_platform driver.
 If you need a device specific setup, you should add a new compatible
 value in the tree and make the driver handle that in whatever
 way you need.


 Arnd 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Arnd Bergmann]

On Wednesday 10 September 2008, Sébastien Chrétien wrote:
 I looked falconide.c, it uses hw_regs_t hw; and ide_hwif_t *hwif.
 Is it a good way ?
 

No, that uses the legacy IDE drivers, not the current ATA drivers,
and it is not based on the device tree information.

Just use drivers/ata/pata_of_platform.c, you probably don't even
need to change the code, just your device tree.

Arnd 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Sergei Shtylyov]

Arnd Bergmann wrote:

  Most probably you can use the existing platform drivers: 
drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c.
Create/register a platform device named pata_platform with 2 memory 
and 1 IRQ resource, and enable one of those drivers.



For new boards using a flattened device tree, it should be enough
to add a device node for the pata_of_platform driver.


   Oops, forgot about this one. No wonder, after being knee deep in ARM for 
several months. :-)


MBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: IDE

[Sébastien Chrétien]

ok I will use the flat device tree.
Do you utils in order to use ata and check ata link ?
For example, to read some information of my compact flash

2008/9/10, Sergei Shtylyov [EMAIL PROTECTED]:

 Arnd Bergmann wrote:

   Most probably you can use the existing platform drivers:
 drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c.
 Create/register a platform device named pata_platform with 2 memory and
 1 IRQ resource, and enable one of those drivers.


  For new boards using a flattened device tree, it should be enough
 to add a device node for the pata_of_platform driver.


   Oops, forgot about this one. No wonder, after being knee deep in ARM for
 several months. :-)

 MBR, Sergei

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Bartlomiej Zolnierkiewicz]

On Thursday 31 July 2008, Bartlomiej Zolnierkiewicz wrote:

[...]

Sorry if my mails were a bit harsh but nobody likes to be pushed around.

[ It is not like I don't want to add proper hot-plugging support or do test
  on more hardware but my time schedule is already tight enough and there are
  still more fundamental things to address (which take priority). ]

 -host-dev[0] = hws[0]-dev;
 +host-dev[0] = hws[0]-parent ? hws[0]-parent : hws[0]-dev;
 
 Could you please try it together with my previous patch for
 ide_device_{get,put}()?

Please test it when you have some time.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

On Fri, 2008-08-01 at 12:54 +0200, Bartlomiej Zolnierkiewicz wrote:
 On Thursday 31 July 2008, Bartlomiej Zolnierkiewicz wrote:
 
 [...]
 
 Sorry if my mails were a bit harsh but nobody likes to be pushed around.
 
 [ It is not like I don't want to add proper hot-plugging support or do test
   on more hardware but my time schedule is already tight enough and there are
   still more fundamental things to address (which take priority). ]
 
  -host-dev[0] = hws[0]-dev;
  +host-dev[0] = hws[0]-parent ? hws[0]-parent : 
  hws[0]-dev;
  
  Could you please try it together with my previous patch for
  ide_device_{get,put}()?
 
 Please test it when you have some time.

The problem in that case is access to the HW :-) I have plenty ide-pmac
based machines but only one or two old laptop (ie. Paul has one too)
with a media-bay and those are in the office. So I'll test on Monday
when I get there, unless I get a chance to pop by on Sunday but that's
unlikely.

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Alan Cox]

 There seems to be some confusion between warm-plugging of IDE devices
 and hot-plugging of IDE devices.
 
  not a single piece of HW to exercise those code path ? I don't ask you
  to get a powermac with a media-bay, but ide_cs seems to be a pretty
  important one that's part of what the ide maintainer should take care
  of... And I suspect it's going to exercise the same code path as
  mediabay.

That confuses people sometimes - ide_cs is a controller hotplug not a
device hotplug ...

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

On Thu, 2008-07-31 at 09:49 +0100, Alan Cox wrote:
  There seems to be some confusion between warm-plugging of IDE devices
  and hot-plugging of IDE devices.
  
   not a single piece of HW to exercise those code path ? I don't ask you
   to get a powermac with a media-bay, but ide_cs seems to be a pretty
   important one that's part of what the ide maintainer should take care
   of... And I suspect it's going to exercise the same code path as
   mediabay.
 
 That confuses people sometimes - ide_cs is a controller hotplug not a
 device hotplug ...

I could make the media-bay look like a controller hotplug if it was
going to make things easier...

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Alan Cox]

 I could make the media-bay look like a controller hotplug if it was
 going to make things easier...

I'm not sure it will. It may do nowdays, but the older IDE code
historically was fairly broken for both cases except in 2.4. Also faking
it as controller hotplug is the wrong path for libata which does real
drive hot plug.


Alan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

On Thu, 2008-07-31 at 10:13 +0100, Alan Cox wrote:
  I could make the media-bay look like a controller hotplug if it was
  going to make things easier...
 
 I'm not sure it will. It may do nowdays, but the older IDE code
 historically was fairly broken for both cases except in 2.4. Also faking
 it as controller hotplug is the wrong path for libata which does real
 drive hot plug.

Yeah, that was my line of thinking initially, also the fact that it has
the nice side effect of keeping the minor number stable.

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Bartlomiej Zolnierkiewicz]

On Thursday 31 July 2008, Benjamin Herrenschmidt wrote:
 
  Is it actually caused by additional reference counting on drive-gendev?
  IOW if you reverse the patch below instead of applying the previous fix
  do things work OK again?
  
   Note that there shouldn't be anything fundamentally different from
   ide-pmac here vs. something like pcmcia IDE cards... do you have one of
   these to test with ?
  
  Nope and I really don't intend to have one.  I count on other people
  to take some care of support for host drivers that they maintain/use. ;)
 
 Reverting the patch below does the job. Thanks.

Thanks, this narrows down the problem pretty nicely.

[ Unfortunately we cannot revert the whole patch as it would break
  unloading of IDE host drivers modules so I still need you help on
  fixing this one. ]

Lets get back to the oops:

Vector: 300 (Data Access) at [c59dfdc0]
    pc: c0211f78: ide_device_put+0x18/0x58
    lr: c0223c34: ide_cd_put+0x40/0x5c
    sp: c59dfe70
   msr: 9032
   dar: 10
 dsisr: 4000
  current = 0xc58a9880
    pid   = 843, comm = media-bay
enter ? for help
[c59dfe80] c0223c34 ide_cd_put+0x40/0x5c
[c59dfea0] c02114d4 generic_ide_remove+0x28/0x3c
[c59dfeb0] c01ea108 __device_release_driver+0x78/0xb4
[c59dfec0] c01ea218 device_release_driver+0x28/0x44
[c59dfee0] c01e9350 bus_remove_device+0xac/0xd8
[c59dff00] c01e77f8 device_del+0x104/0x198
[c59dff20] c01e78a4 device_unregister+0x18/0x30
[c59dff40] c0212598 __ide_port_unregister_devices+0x6c/0x88
[c59dff60] c021276c ide_port_unregister_devices+0x38/0x80
[c59dff80] c0209078 media_bay_step+0x1cc/0x5c0
[c59dffb0] c02094f8 media_bay_task+0x8c/0xcc
[c59dffd0] c0048640 kthread+0x48/0x84
[c59dfff0] c0011b38 kernel_thread+0x44/0x60

On a fresh look at ide_device_put(), ide_host_alloc() and pmac.c
it may be that the above oops is actually media-bay specific.

ide_device_put():
...
struct device *host_dev = drive-hwif-host-dev[0];
struct module *module = host_dev ? host_dev-driver-owner : NULL;
...

ide_host_alloc():
...
   if (hws[0])
host-dev[0] = hws[0]-dev;
...

pmac.c:
...
pmac_ide_macio_attach(struct macio_dev *mdev, const struct of_device_id *match)
...
dev_set_drvdata(mdev-ofdev.dev, pmif);

memset(hw, 0, sizeof(hw));
pmac_ide_init_ports(hw, pmif-regbase);
hw.irq = irq;
hw.dev = mdev-bus-pdev-dev;
hw.parent = mdev-ofdev.dev;
...

pmac macio is unique in using different devices for hwif-dev / host-dev
(hw.dev) and hwif-gendev.parent / dev_set_drvdata() (hw.parent)

[ I has been actually wondering why is it so for some time...? ]

Thus we may be hitting oops in ide_device_put() on host_dev-driver
because hw.dev is used as host-dev for pmac macio in ide_device_put()
while we really want to use hw.parent.

Fix should be as simple as:

-host-dev[0] = hws[0]-dev;
+host-dev[0] = hws[0]-parent ? hws[0]-parent : hws[0]-dev;

Could you please try it together with my previous patch for
ide_device_{get,put}()?

Bart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

On Tue, 2008-07-29 at 21:26 +0200, Bartlomiej Zolnierkiewicz wrote:

 I WON!!!

Only half...

It goes further and then blows up again. First problem is, this
unregister interface doesn't quite convey the fact that the HW is gone
and the IDE code seems to take it's sweet time figuring it out after
trying some requests. Maybe something smarter can be done here ? ie,
ide_set_interface_dead() :-)

mediabay0: switching to 7
mediabay0: powering down
media bay 0 is empty
hdc: status error: status=0x00 { }
ide: failed opcode was: unknown
hdc: status error: status=0x00 { }
ide: failed opcode was: unknown

Then after this couple of failed attempts at sending commands, it
crashes with the backtrace below. Another NULL dereference apparently,
though the DAR value (the faulting address) has been slightly different
between consecutive tests so it may be a use-after-free too.

Note that there shouldn't be anything fundamentally different from
ide-pmac here vs. something like pcmcia IDE cards... do you have one of
these to test with ?

Vector: 300 (Data Access) at [c59dfdc0]
pc: c0211f78: ide_device_put+0x18/0x58
lr: c0223c34: ide_cd_put+0x40/0x5c
sp: c59dfe70
   msr: 9032
   dar: 10
 dsisr: 4000
  current = 0xc58a9880
pid   = 843, comm = media-bay
enter ? for help
[c59dfe80] c0223c34 ide_cd_put+0x40/0x5c
[c59dfea0] c02114d4 generic_ide_remove+0x28/0x3c
[c59dfeb0] c01ea108 __device_release_driver+0x78/0xb4
[c59dfec0] c01ea218 device_release_driver+0x28/0x44
[c59dfee0] c01e9350 bus_remove_device+0xac/0xd8
[c59dff00] c01e77f8 device_del+0x104/0x198
[c59dff20] c01e78a4 device_unregister+0x18/0x30
[c59dff40] c0212598 __ide_port_unregister_devices+0x6c/0x88
[c59dff60] c021276c ide_port_unregister_devices+0x38/0x80
[c59dff80] c0209078 media_bay_step+0x1cc/0x5c0
[c59dffb0] c02094f8 media_bay_task+0x8c/0xcc
[c59dffd0] c0048640 kthread+0x48/0x84
[c59dfff0] c0011b38 kernel_thread+0x44/0x60


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Bartlomiej Zolnierkiewicz]

On Wednesday 30 July 2008, Benjamin Herrenschmidt wrote:
 On Tue, 2008-07-29 at 21:26 +0200, Bartlomiej Zolnierkiewicz wrote:
 
  I WON!!!
 
 Only half...

Heh, I wasn't talking about fixing the issue...
(hint: look up the author of the bad commit).

 It goes further and then blows up again. First problem is, this
 unregister interface doesn't quite convey the fact that the HW is gone
 and the IDE code seems to take it's sweet time figuring it out after
 trying some requests. Maybe something smarter can be done here ? ie,
 ide_set_interface_dead() :-)

Sure, it would be great to have controller hotplug working reliably
one day but the recent patches shouldn't really be making things worse
(quite the contrary) so I would prefer to find and learn more about
the cause of regression first.

[ However nothing prevents us from improving the hotplug support in
  parallel to fixing the issue so if you have some ideas that could
  be conveyed in form of patches please go ahead. ]

 mediabay0: switching to 7
 mediabay0: powering down
 media bay 0 is empty
 hdc: status error: status=0x00 { }
 ide: failed opcode was: unknown
 hdc: status error: status=0x00 { }
 ide: failed opcode was: unknown
 
 Then after this couple of failed attempts at sending commands, it
 crashes with the backtrace below. Another NULL dereference apparently,
 though the DAR value (the faulting address) has been slightly different
 between consecutive tests so it may be a use-after-free too.

Is it actually caused by additional reference counting on drive-gendev?
IOW if you reverse the patch below instead of applying the previous fix
do things work OK again?

 Note that there shouldn't be anything fundamentally different from
 ide-pmac here vs. something like pcmcia IDE cards... do you have one of
 these to test with ?

Nope and I really don't intend to have one.  I count on other people
to take some care of support for host drivers that they maintain/use. ;)

Thanks,
Bart

diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 4e73aee..8f253e5 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -57,23 +57,29 @@ static DEFINE_MUTEX(idecd_ref_mutex);
 #define ide_cd_g(disk) \
container_of((disk)-private_data, struct cdrom_info, driver)
 
+static void ide_cd_release(struct kref *);
+
 static struct cdrom_info *ide_cd_get(struct gendisk *disk)
 {
struct cdrom_info *cd = NULL;
 
mutex_lock(idecd_ref_mutex);
cd = ide_cd_g(disk);
-   if (cd)
+   if (cd) {
kref_get(cd-kref);
+   if (ide_device_get(cd-drive)) {
+   kref_put(cd-kref, ide_cd_release);
+   cd = NULL;
+   }
+   }
mutex_unlock(idecd_ref_mutex);
return cd;
 }
 
-static void ide_cd_release(struct kref *);
-
 static void ide_cd_put(struct cdrom_info *cd)
 {
mutex_lock(idecd_ref_mutex);
+   ide_device_put(cd-drive);
kref_put(cd-kref, ide_cd_release);
mutex_unlock(idecd_ref_mutex);
 }

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

On Wed, 2008-07-30 at 21:11 +0200, Bartlomiej Zolnierkiewicz wrote:
 
  Note that there shouldn't be anything fundamentally different from
  ide-pmac here vs. something like pcmcia IDE cards... do you have one
 of
  these to test with ?
 
 Nope and I really don't intend to have one.  I count on other people
 to take some care of support for host drivers that they
 maintain/use. ;)

Hrm... that's not a very sane approach. You have some infrastructure for
adding / removing devices, in fact changes things in that area even, and
not a single piece of HW to exercise those code path ? I don't ask you
to get a powermac with a media-bay, but ide_cs seems to be a pretty
important one that's part of what the ide maintainer should take care
of... And I suspect it's going to exercise the same code path as
mediabay.

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Bartlomiej Zolnierkiewicz]

On Thursday 31 July 2008, Benjamin Herrenschmidt wrote:
 On Wed, 2008-07-30 at 21:11 +0200, Bartlomiej Zolnierkiewicz wrote:
  
   Note that there shouldn't be anything fundamentally different from
   ide-pmac here vs. something like pcmcia IDE cards... do you have one
  of
   these to test with ?
  
  Nope and I really don't intend to have one.  I count on other people
  to take some care of support for host drivers that they
  maintain/use. ;)
 
 Hrm... that's not a very sane approach. You have some infrastructure for
 adding / removing devices, in fact changes things in that area even, and

There seems to be some confusion between warm-plugging of IDE devices
and hot-plugging of IDE devices.

 not a single piece of HW to exercise those code path ? I don't ask you
 to get a powermac with a media-bay, but ide_cs seems to be a pretty
 important one that's part of what the ide maintainer should take care
 of... And I suspect it's going to exercise the same code path as
 mediabay.

I'm open for offers of co-maintaince of the code (which includes taking
over particular host drivers) and since you seem to have pretty good
insight into what ide maintainer should be doing I presume that you want
to be added to MAINTAINERS?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

On Thu, 2008-07-31 at 02:48 +0200, Bartlomiej Zolnierkiewicz wrote:
 There seems to be some confusion between warm-plugging of IDE devices
 and hot-plugging of IDE devices.
 
  not a single piece of HW to exercise those code path ? I don't ask you
  to get a powermac with a media-bay, but ide_cs seems to be a pretty
  important one that's part of what the ide maintainer should take care
  of... And I suspect it's going to exercise the same code path as
  mediabay.
 
 I'm open for offers of co-maintaince of the code (which includes taking
 over particular host drivers) and since you seem to have pretty good
 insight into what ide maintainer should be doing I presume that you want
 to be added to MAINTAINERS?

Should I laugh ?

Seriously here. Those things used to work, you broke them.

It may be worthwile cleanup / improvements, but at the end of the day,
if you are the maintainer for drivers/ide, and things as fundamental as
supporting proper ide_cs seems to be totally part of your job. I'm not
saying ide_cs is broken today (though I suspect it -may- be suffering
from similar breakage to media-bay), however, I'm reacting to your
apparent lack of interest in making sure these things work.

Ben.



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Bartlomiej Zolnierkiewicz]

On Thursday 31 July 2008, Benjamin Herrenschmidt wrote:
 On Thu, 2008-07-31 at 02:48 +0200, Bartlomiej Zolnierkiewicz wrote:
  There seems to be some confusion between warm-plugging of IDE devices
  and hot-plugging of IDE devices.
  
   not a single piece of HW to exercise those code path ? I don't ask you
   to get a powermac with a media-bay, but ide_cs seems to be a pretty
   important one that's part of what the ide maintainer should take care
   of... And I suspect it's going to exercise the same code path as
   mediabay.
  
  I'm open for offers of co-maintaince of the code (which includes taking
  over particular host drivers) and since you seem to have pretty good
  insight into what ide maintainer should be doing I presume that you want
  to be added to MAINTAINERS?
 
 Should I laugh ?
 
 Seriously here. Those things used to work, you broke them.

That's jumping to conlusions as you haven't yet proven that it was
really me. :)

Which would be great because than I can finally start fixing the damage.

 It may be worthwile cleanup / improvements, but at the end of the day,
 if you are the maintainer for drivers/ide, and things as fundamental as
 supporting proper ide_cs seems to be totally part of your job. I'm not

Maybe I'm really completely unsuited for the job.  I even didn't know
that proper supporting of _one_ particular host driver is a _fundamental_
part of the _subsystem_ maintainer's job...

 saying ide_cs is broken today (though I suspect it -may- be suffering
 from similar breakage to media-bay), however, I'm reacting to your
 apparent lack of interest in making sure these things work.

If only all people showed so much interest as *IDE*PMAC* Maintainer in
making sure that things work (instead of i.e. telling people what should
they be doing in their _limited_ _private_ time) we would have nothing
to worry about! ;)

Can we now go back to fixing ide-pmac breakage?  Pretty please.

It is not unlikely that it in the time it took for the last four
mails it would have been fixed already.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

 Is it actually caused by additional reference counting on drive-gendev?
 IOW if you reverse the patch below instead of applying the previous fix
 do things work OK again?
 
  Note that there shouldn't be anything fundamentally different from
  ide-pmac here vs. something like pcmcia IDE cards... do you have one of
  these to test with ?
 
 Nope and I really don't intend to have one.  I count on other people
 to take some care of support for host drivers that they maintain/use. ;)

Reverting the patch below does the job. Thanks.

Ben.

 Thanks,
 Bart
 
 diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
 index 4e73aee..8f253e5 100644
 --- a/drivers/ide/ide-cd.c
 +++ b/drivers/ide/ide-cd.c
 @@ -57,23 +57,29 @@ static DEFINE_MUTEX(idecd_ref_mutex);
  #define ide_cd_g(disk) \
   container_of((disk)-private_data, struct cdrom_info, driver)
  
 +static void ide_cd_release(struct kref *);
 +
  static struct cdrom_info *ide_cd_get(struct gendisk *disk)
  {
   struct cdrom_info *cd = NULL;
  
   mutex_lock(idecd_ref_mutex);
   cd = ide_cd_g(disk);
 - if (cd)
 + if (cd) {
   kref_get(cd-kref);
 + if (ide_device_get(cd-drive)) {
 + kref_put(cd-kref, ide_cd_release);
 + cd = NULL;
 + }
 + }
   mutex_unlock(idecd_ref_mutex);
   return cd;
  }
  
 -static void ide_cd_release(struct kref *);
 -
  static void ide_cd_put(struct cdrom_info *cd)
  {
   mutex_lock(idecd_ref_mutex);
 + ide_device_put(cd-drive);
   kref_put(cd-kref, ide_cd_release);
   mutex_unlock(idecd_ref_mutex);
  }

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Bartlomiej Zolnierkiewicz]

On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote:
 On Tue, 2008-07-29 at 14:17 +0900, FUJITA Tomonori wrote:
  If q-elevator is NULL, the media-bay code might mess up the ref
  counting of the request queue...
 
 Well, all I do is call into Bart's new helpers to scan for or unregister
 devices ...

The switch to these helpers happened _before_ 2.6.26 and it shouldn't bring
such behavior change (ditto for new IDE host addition/removal helpers)...

Please try to git-bisect it when you have some time.

Thanks,
Bart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

On Tue, 2008-07-29 at 13:41 +0200, Bartlomiej Zolnierkiewicz wrote:
  Well, all I do is call into Bart's new helpers to scan for or
 unregister
  devices ...
 
 The switch to these helpers happened _before_ 2.6.26 and it shouldn't
 bring
 such behavior change (ditto for new IDE host addition/removal
 helpers)...
 
 Please try to git-bisect it when you have some time.

Ok, I will. I worked fine when I last tried your patches. I'll see if I
can track it down too. Been a bit too busy lately as you can imagine.

Do you have something that exercise the same code path you can use ?

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Bartlomiej Zolnierkiewicz]

On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote:
 On Tue, 2008-07-29 at 13:41 +0200, Bartlomiej Zolnierkiewicz wrote:
   Well, all I do is call into Bart's new helpers to scan for or
  unregister
   devices ...
  
  The switch to these helpers happened _before_ 2.6.26 and it shouldn't
  bring
  such behavior change (ditto for new IDE host addition/removal
  helpers)...
  
  Please try to git-bisect it when you have some time.
 
 Ok, I will. I worked fine when I last tried your patches. I'll see if I
 can track it down too. Been a bit too busy lately as you can imagine.
 
 Do you have something that exercise the same code path you can use ?

I'll see if I can reproduce it with IDE warm-plug support later...

Thanks,
Bart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

 I WON!!!

Heh, great :-)

I'll give you patch a try, thanks !

Cheers,
Ben.

 From: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
 Subject: [PATCH] ide: fix regression caused by ide_device_{get,put}() addition
 
 On Monday 28 July 2008, Benjamin Herrenschmidt wrote:
 
 [...]
 
  Vector: 300 (Data Access) at [c58b7b80]
  pc: c014f264: elv_may_queue+0x10/0x44
  lr: c0152750: get_request+0x2c/0x2c0
  sp: c58b7c30
 msr: 1032
 dar: c
   dsisr: 4000
current = 0xc58aaae0
  pid   = 854, comm = media-bay
  enter ? for help
  mon t
  [c58b7c40] c0152750 get_request+0x2c/0x2c0
  [c58b7c70] c0152a08 get_request_wait+0x24/0xec
  [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0
  [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc
  [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0
  [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c
  [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8
  [c58b7e50] c022395c ide_cd_release+0x80/0x84
  [c58b7e70] c0163650 kref_put+0x54/0x6c
  [c58b7e80] c0223884 ide_cd_put+0x40/0x5c
  [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c
  [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4
  [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44
  [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8
  [c58b7f00] c01e7424 device_del+0x104/0x198
  [c58b7f20] c01e74d0 device_unregister+0x18/0x30
  [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88
  [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80
  [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0
  [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc
  [c58b7fd0] c00485c0 kthread+0x48/0x84
  [c58b7ff0] c0011b20 kernel_thread+0x44/0x60
 
 The guilty commit turned out to be 08da591e14cf87247ec09b17c350235157a92fc3
 (ide: add ide_device_{get,put}() helpers).  ide_device_put() is called
 before kref_put() in ide_cd_put() so IDE device is already gone by the time
 ide_cd_release() is reached.
 
 Fix it by calling ide_device_get() before kref_get() and ide_device_put()
 after kref_put() in all affected device drivers.
 
 Reported-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
 Cc: FUJITA Tomonori [EMAIL PROTECTED]
 Cc: Borislav Petkov [EMAIL PROTECTED]
 Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
 ---
  drivers/ide/ide-cd.c |   10 +-
  drivers/ide/ide-disk.c   |9 -
  drivers/ide/ide-floppy.c |9 -
  drivers/ide/ide-tape.c   |9 -
  drivers/scsi/ide-scsi.c  |9 -
  5 files changed, 21 insertions(+), 25 deletions(-)
 
 Index: b/drivers/ide/ide-cd.c
 ===
 --- a/drivers/ide/ide-cd.c
 +++ b/drivers/ide/ide-cd.c
 @@ -66,11 +66,11 @@ static struct cdrom_info *ide_cd_get(str
   mutex_lock(idecd_ref_mutex);
   cd = ide_cd_g(disk);
   if (cd) {
 - kref_get(cd-kref);
 - if (ide_device_get(cd-drive)) {
 - kref_put(cd-kref, ide_cd_release);
 + if (ide_device_get(cd-drive))
   cd = NULL;
 - }
 + else
 + kref_get(cd-kref);
 +
   }
   mutex_unlock(idecd_ref_mutex);
   return cd;
 @@ -79,8 +79,8 @@ static struct cdrom_info *ide_cd_get(str
  static void ide_cd_put(struct cdrom_info *cd)
  {
   mutex_lock(idecd_ref_mutex);
 - ide_device_put(cd-drive);
   kref_put(cd-kref, ide_cd_release);
 + ide_device_put(cd-drive);
   mutex_unlock(idecd_ref_mutex);
  }
  
 Index: b/drivers/ide/ide-disk.c
 ===
 --- a/drivers/ide/ide-disk.c
 +++ b/drivers/ide/ide-disk.c
 @@ -65,11 +65,10 @@ static struct ide_disk_obj *ide_disk_get
   mutex_lock(idedisk_ref_mutex);
   idkp = ide_disk_g(disk);
   if (idkp) {
 - kref_get(idkp-kref);
 - if (ide_device_get(idkp-drive)) {
 - kref_put(idkp-kref, ide_disk_release);
 + if (ide_device_get(idkp-drive))
   idkp = NULL;
 - }
 + else
 + kref_get(idkp-kref);
   }
   mutex_unlock(idedisk_ref_mutex);
   return idkp;
 @@ -78,8 +77,8 @@ static struct ide_disk_obj *ide_disk_get
  static void ide_disk_put(struct ide_disk_obj *idkp)
  {
   mutex_lock(idedisk_ref_mutex);
 - ide_device_put(idkp-drive);
   kref_put(idkp-kref, ide_disk_release);
 + ide_device_put(idkp-drive);
   mutex_unlock(idedisk_ref_mutex);
  }
  
 Index: b/drivers/ide/ide-floppy.c
 ===
 --- a/drivers/ide/ide-floppy.c
 +++ b/drivers/ide/ide-floppy.c
 @@ -167,11 +167,10 @@ static struct ide_floppy_obj *ide_floppy
   mutex_lock(idefloppy_ref_mutex);
   floppy = ide_floppy_g(disk);
   if (floppy) {
 - kref_get(floppy-kref);
 - if (ide_device_get(floppy-drive)) {
 - kref_put(floppy-kref, idefloppy_cleanup_obj);
 + if 

Re: ide pmac breakage

[FUJITA Tomonori]

On Tue, 29 Jul 2008 21:26:11 +0200
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:

 On Tuesday 29 July 2008, Bartlomiej Zolnierkiewicz wrote:
  On Tuesday 29 July 2008, Bartlomiej Zolnierkiewicz wrote:
   On Tuesday 29 July 2008, Benjamin Herrenschmidt wrote:
On Tue, 2008-07-29 at 13:41 +0200, Bartlomiej Zolnierkiewicz wrote:
  Well, all I do is call into Bart's new helpers to scan for or
 unregister
  devices ...
 
 The switch to these helpers happened _before_ 2.6.26 and it shouldn't
 bring
 such behavior change (ditto for new IDE host addition/removal
 helpers)...
 
 Please try to git-bisect it when you have some time.

Ok, I will. I worked fine when I last tried your patches. I'll see if I
can track it down too. Been a bit too busy lately as you can imagine.

Do you have something that exercise the same code path you can use ?
   
   I'll see if I can reproduce it with IDE warm-plug support later...
  
  OK, I reproduced it here with IDE warm-plug support
  (echo -n 1  /sys/class/ide_port/ide*/delete_devices)
  for devices driven by ide-cd.
  
  It is also reproducible under qemu so I'm scripting it
  into git-bisect run now...
 
 I WON!!!

Great, seems that I don't need to learn how ide does ref counting. :)

Thanks a lot!
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Bartlomiej Zolnierkiewicz]

On Monday 28 July 2008, Benjamin Herrenschmidt wrote:
 On Mon, 2008-07-28 at 11:29 +1000, Benjamin Herrenschmidt wrote:
  The current ide-pmac upstream is broken. It calls
  media_bay_set_ide_infos() with an uninitialized hwif argument.
  
  It's not a trivial mistake, there's a chicken-and-egg problem in the
  init code in there.
  
  I've locally fixed it with this patch that i'll merge via the powerpc
  tree unless you have an objection.

Fine with me (you may add my ACK) and thanks for fixing it.

  However, the machine crashes when removing the media-bay CD-ROM drive.
  
  Crash appears to be a NULL deref, possibly in elv_may_queue() though
  I don't have a clean backtrace yet, working on it...

I wonder whether conversion from on-stack struct requests to allocated
ones may have something to do with it (or not?)...

 Here's a backtrace:
 
 Vector: 300 (Data Access) at [c58b7b80]
 pc: c014f264: elv_may_queue+0x10/0x44
 lr: c0152750: get_request+0x2c/0x2c0
 sp: c58b7c30
msr: 1032
dar: c
  dsisr: 4000
   current = 0xc58aaae0
 pid   = 854, comm = media-bay
 enter ? for help
 mon t
 [c58b7c40] c0152750 get_request+0x2c/0x2c0
 [c58b7c70] c0152a08 get_request_wait+0x24/0xec
 [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0
 [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc
 [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0
 [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c
 [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8
 [c58b7e50] c022395c ide_cd_release+0x80/0x84
 [c58b7e70] c0163650 kref_put+0x54/0x6c
 [c58b7e80] c0223884 ide_cd_put+0x40/0x5c
 [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c
 [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4
 [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44
 [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8
 [c58b7f00] c01e7424 device_del+0x104/0x198
 [c58b7f20] c01e74d0 device_unregister+0x18/0x30
 [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88
 [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80
 [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0
 [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc
 [c58b7fd0] c00485c0 kthread+0x48/0x84
 [c58b7ff0] c0011b20 kernel_thread+0x44/0x60
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

On Tue, 2008-07-29 at 14:17 +0900, FUJITA Tomonori wrote:
 If q-elevator is NULL, the media-bay code might mess up the ref
 counting of the request queue...

Well, all I do is call into Bart's new helpers to scan for or unregister
devices ...

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[FUJITA Tomonori]

On Mon, 28 Jul 2008 16:31:56 +0200
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:

   However, the machine crashes when removing the media-bay CD-ROM drive.
   
   Crash appears to be a NULL deref, possibly in elv_may_queue() though
   I don't have a clean backtrace yet, working on it...
 
 I wonder whether conversion from on-stack struct requests to allocated
 ones may have something to do with it (or not?)...

It might be. q-elevator is NULL?

I think that everyone goes through this path (generic_ide_remove -
ide_cd_release - cdrom_get_disc_info -...). With 2.6.27-rc1, I've
just tried this path by removing ide-cd module, and it's fine.

If q-elevator is NULL, the media-bay code might mess up the ref
counting of the request queue...


  Here's a backtrace:
  
  Vector: 300 (Data Access) at [c58b7b80]
  pc: c014f264: elv_may_queue+0x10/0x44
  lr: c0152750: get_request+0x2c/0x2c0
  sp: c58b7c30
 msr: 1032
 dar: c
   dsisr: 4000
current = 0xc58aaae0
  pid   = 854, comm = media-bay
  enter ? for help
  mon t
  [c58b7c40] c0152750 get_request+0x2c/0x2c0
  [c58b7c70] c0152a08 get_request_wait+0x24/0xec
  [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0
  [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc
  [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0
  [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c
  [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8
  [c58b7e50] c022395c ide_cd_release+0x80/0x84
  [c58b7e70] c0163650 kref_put+0x54/0x6c
  [c58b7e80] c0223884 ide_cd_put+0x40/0x5c
  [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c
  [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4
  [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44
  [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8
  [c58b7f00] c01e7424 device_del+0x104/0x198
  [c58b7f20] c01e74d0 device_unregister+0x18/0x30
  [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88
  [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80
  [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0
  [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc
  [c58b7fd0] c00485c0 kthread+0x48/0x84
  [c58b7ff0] c0011b20 kernel_thread+0x44/0x60
 
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ide pmac breakage

[Benjamin Herrenschmidt]

On Mon, 2008-07-28 at 11:29 +1000, Benjamin Herrenschmidt wrote:
 The current ide-pmac upstream is broken. It calls
 media_bay_set_ide_infos() with an uninitialized hwif argument.
 
 It's not a trivial mistake, there's a chicken-and-egg problem in the
 init code in there.
 
 I've locally fixed it with this patch that i'll merge via the powerpc
 tree unless you have an objection.
 
 However, the machine crashes when removing the media-bay CD-ROM drive.
 
 Crash appears to be a NULL deref, possibly in elv_may_queue() though
 I don't have a clean backtrace yet, working on it...

Here's a backtrace:

Vector: 300 (Data Access) at [c58b7b80]
pc: c014f264: elv_may_queue+0x10/0x44
lr: c0152750: get_request+0x2c/0x2c0
sp: c58b7c30
   msr: 1032
   dar: c
 dsisr: 4000
  current = 0xc58aaae0
pid   = 854, comm = media-bay
enter ? for help
mon t
[c58b7c40] c0152750 get_request+0x2c/0x2c0
[c58b7c70] c0152a08 get_request_wait+0x24/0xec
[c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0
[c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc
[c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0
[c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c
[c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8
[c58b7e50] c022395c ide_cd_release+0x80/0x84
[c58b7e70] c0163650 kref_put+0x54/0x6c
[c58b7e80] c0223884 ide_cd_put+0x40/0x5c
[c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c
[c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4
[c58b7ec0] c01e9e44 device_release_driver+0x28/0x44
[c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8
[c58b7f00] c01e7424 device_del+0x104/0x198
[c58b7f20] c01e74d0 device_unregister+0x18/0x30
[c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88
[c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80
[c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0
[c58b7fb0] c0209124 media_bay_task+0x8c/0xcc
[c58b7fd0] c00485c0 kthread+0x48/0x84
[c58b7ff0] c0011b20 kernel_thread+0x44/0x60


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev