No Subject

No Subject

[jingai]

This may not be the appropriate list to post this on, but since it
does work on my x86 box at work, here goes...

I'm having trouble burning multisession discs with cdrdao.  My
TOC file is as follows:

CD_ROM_XA
TRACK AUDIO
FILE "audio.raw" 0

TRACK MODE2_FORM1
DATAFILE "data.raw"

And the command line:

cdrdao write --multi --device 1,4,0 my.toc

Here is the output from cdrdao:

Cdrdao version 1.1.3 - (C) Andreas Mueller <mueller@daneb.ping.de>
  SCSI interface library - (C) Joerg Schilling
  L-EC encoding library - (C) Heiko Eissfeldt
  Paranoia DAE library - (C) Monty

1,4,0: YAMAHA CRW6416S  Rev: 1.0c
Using driver: Generic SCSI-3/MMC - Version 1.0 (data) (options 0x0000)

Starting write simulation at speed 6...
Pausing 10 seconds - hit CTRL-C to abort.
Process can be aborted with QUIT signal (usually CTRL-\).
Using POSIX real time scheduling.
Executing power calibration...
cdrdao: No such device or address. Cannot set SG_SET_TIMEOUT.

It is apparently failing on the power calibration, but with the same
CD writer at work, it does not fail here.

My second problem happens both on x86 and PowerPC.  If I
specify the --multi option to cdrdao, it fails shortly after the
burn begins (it does write some data to the disc though) with
a buffer underrun.  If I omit the --multi option, it burns fine
on x86.  Seeing as I am trying to burn a multisession disc,
it's kind of necessary (I think?) to specify the --multi
option.

Both boxes are running Debian woody and kernel 2.2.18pre21.

Any help would be greatly appreciated.

Regards,
Jonathan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Multisession CDRs

[Daniel Eisenbud]

Hi,
	I'm trying to track down an apparent bug that causes the SCSI
bus on my mac to freeze when I try to burn a disk in disk-at-once mode.
I have three questions for you: have you ever managed to burn a disk
with cdrdao with any options on your powerpc machine?  When it fails,
does it lock up the whole SCSI bus, renedering the machine unusable, or
can you go on without a reboot?  And finally, what kind of hardware do
you have?

Thanks,
Daniel Eisenbud

On Sun, Nov 19, 2000 at 03:02:08PM -0500, jingai <jingai@floatingpenguins.com> wrote:
> This may not be the appropriate list to post this on, but since it
> does work on my x86 box at work, here goes...
>
> I'm having trouble burning multisession discs with cdrdao.  My
> TOC file is as follows:
>
> CD_ROM_XA
> TRACK AUDIO
> FILE "audio.raw" 0
>
> TRACK MODE2_FORM1
> DATAFILE "data.raw"
>
> And the command line:
>
> cdrdao write --multi --device 1,4,0 my.toc
>
> Here is the output from cdrdao:
>
> Cdrdao version 1.1.3 - (C) Andreas Mueller <mueller@daneb.ping.de>
>   SCSI interface library - (C) Joerg Schilling
>   L-EC encoding library - (C) Heiko Eissfeldt
>   Paranoia DAE library - (C) Monty
>
> 1,4,0: YAMAHA CRW6416S  Rev: 1.0c
> Using driver: Generic SCSI-3/MMC - Version 1.0 (data) (options 0x0000)
>
> Starting write simulation at speed 6...
> Pausing 10 seconds - hit CTRL-C to abort.
> Process can be aborted with QUIT signal (usually CTRL-\).
> Using POSIX real time scheduling.
> Executing power calibration...
> cdrdao: No such device or address. Cannot set SG_SET_TIMEOUT.
>
> It is apparently failing on the power calibration, but with the same
> CD writer at work, it does not fail here.
>
> My second problem happens both on x86 and PowerPC.  If I
> specify the --multi option to cdrdao, it fails shortly after the
> burn begins (it does write some data to the disc though) with
> a buffer underrun.  If I omit the --multi option, it burns fine
> on x86.  Seeing as I am trying to burn a multisession disc,
> it's kind of necessary (I think?) to specify the --multi
> option.
>
> Both boxes are running Debian woody and kernel 2.2.18pre21.
>
> Any help would be greatly appreciated.
>
> Regards,
> Jonathan

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: No Subject

[Benjamin Herrenschmidt]

On Sun, 2004-01-25 at 22:31, Geert Uytterhoeven wrote:
> 	Hi,
>
> This patch converts <asm/hydra.h> to use explicit-sized types.
> It also applies to 2.4.

Don't you want to port the Hydra code to use the macio infrastructure ?

It would probably require defining the LongTrail as a _MACH_Pmac or
hacking enough of pmac_feature to grok it, but that doesn't seem to
bad actually...

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

(no subject)

[kou.ishizaki]

jgarzik@pobox.com, jim@jklewis.com
Subject: Re: [Cbe-oss-dev] spidernet: dynamic phy setup code
In-Reply-To: <200701261409.29537.jens@de.ibm.com>
From: Ishizaki Kou <kouish@swc.toshiba.co.jp>
X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jens-san

> This patch modifies the patch submitted by Kou Ishizaki to make it
work on the
> blade
(http://marc.theaimsgroup.com/?l=linux-netdev&m=116593424505539&w=2).
> Unfortunately I dont have access to a Celleb so I cannot test it
there.

Thanks for arranging our patch to work on Cell Blade.

This patch partially works on celleb but remains 
following several problems.
1. It doesn't recover once an ethernet cable which is
   connected to a spider_net card is unpluged. 
2. It doesn't work when the spider_net card is connected to 
   a 100Mbps ethernet switch.

To solve these problems, we need to restore some codes
you removed from your patch.

(1)
>- if (card->aneg_count > 10) {
>-  /* timeout */
>-  card->aneg_count = 0;
>-  is1000 = !is1000;
>-  goto re_setup;

>- if (phy->speed == 1000 && !is1000) {
>-  is1000 = 1;
>-  goto re_setup;
>- } else if(phy->speed != 1000 && is1000) {
>-  is1000 = 0;
>-  goto re_setup;
>- }

We need to use different auto-neg initial settings between
for 10/100Mbps ethernet switches and for Gbps ethernet switches.
Driver don't know which type of network switch is connected to
network card, so we try both settings alternately in auto negtiation
sequences by using a variable "is1000".
Furthermore, we have a problem that poll_link() may succeed even when
the auto-neg initial setting is for different network switch type,
and the network card does not work on this case. We retry auto-neg
with the another initial setting on this case.

#We are commented that "is1000" should be in spider_net_card.
#We fixed it in another patch. Please refer the following.
#http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030203.html

But we don't think this is the best solution, and we are still
developing 
our spidernet driver. If you have a good alternative idea, please tell
us.

(2)
>- spider_net_write_reg(card, SPIDER_NET_GMACST,
>-        spider_net_read_reg(card, SPIDER_NET_GMACST));
>- spider_net_write_reg(card, SPIDER_NET_GMACINTEN, 0x4);

These codes are enabling LINK status interrupt which is disabled
at the beginning of auto-neg.
Without this operation, auto negotiation works only when a connection
detected for the first time, and auto negotiation will not work 
when an ethernet cable is unpluged or pluged.

(3)
>- mii_phy_probe(phy, phy->mii_id);
It seems that PHY reset is necessary before auto negotiation,
after a link once went down.
We can't call directly reset routine from driver, so we call
mii_phy_probe().
We are still developping the patch as we noted, and we are considering
to call mii_phy_probe() from spider_net_setup_aneg(), or to call
reset_one_mii_phy() from bcm54xx_setup_aneg().

We think these (1)-(3) are necessary, but we are afraid that you removed
them
by a reason that they causes some trouble in Cell Blade. If so please
tell us.


Best regards,
Kou Ishizaki

Re: No Subject

[Benjamin Herrenschmidt]

> We need to use different auto-neg initial settings between
> for 10/100Mbps ethernet switches and for Gbps ethernet switches.

That is strange ! What PHY chip are you using ? Are you sure it's not
just you not properly configuring the PHY ? Is the datasheet for the PHY
available somewhere ?

> Driver don't know which type of network switch is connected to
> network card, so we try both settings alternately in auto negtiation
> sequences by using a variable "is1000".

sungem has an autoneg sequence that falls back to forced speeds but it's
not useful on any modern setup. Your PHY should be perfectly capable to
autoneg on both 1000bT and 10/100bT...

> Furthermore, we have a problem that poll_link() may succeed even when
> the auto-neg initial setting is for different network switch type,
> and the network card does not work on this case. We retry auto-neg
> with the another initial setting on this case.

Ugh ? What is that initial setting bit exactly ? If the link is up, it
should work.

> >- spider_net_write_reg(card, SPIDER_NET_GMACST,
> >-        spider_net_read_reg(card, SPIDER_NET_GMACST));
> >- spider_net_write_reg(card, SPIDER_NET_GMACINTEN, 0x4);
> 
> These codes are enabling LINK status interrupt which is disabled
> at the beginning of auto-neg.
> Without this operation, auto negotiation works only when a connection
> detected for the first time, and auto negotiation will not work 
> when an ethernet cable is unpluged or pluged.

Most drivers poll the link rather than use an interrupt as those are
often unreliable.

> (3)
> >- mii_phy_probe(phy, phy->mii_id);
> It seems that PHY reset is necessary before auto negotiation,
> after a link once went down.

It shouldn't be... again, what PHY are you using ?

> We can't call directly reset routine from driver, so we call
> mii_phy_probe().

If you really need to reset it, then change sungem_phy.c to export the
reset function. But I'm surprised you need that. Another option is to
reset the PHY in your PHY's setup_aneg() function.

> We are still developping the patch as we noted, and we are considering
> to call mii_phy_probe() from spider_net_setup_aneg(), or to call
> reset_one_mii_phy() from bcm54xx_setup_aneg().
> 
> We think these (1)-(3) are necessary, but we are afraid that you removed
> them
> by a reason that they causes some trouble in Cell Blade. If so please
> tell us.

You might want to borrow the link state machine from sungem.c instead...
it tends to just work :-)

Ben.