* Re: [PATCH] powerpc vdso updates
From: Benjamin Herrenschmidt @ 2006-05-30 7:21 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, linuxppc-dev list, Paul Mackerras,
Linux Kernel list
In-Reply-To: <20060530062447.GD19870@elte.hu>
> get_unmapped_area() without holding the mmap semaphore seems dangerous.
> The VDSO setup itself should be 'private' to the process, but i'm not
> totally sure that no other kernel code could get access to this mm. For
> example the swapout code? Am i missing something?
Well, all of this happens so early, I doubt anything will cause actual
harm, for get_unmapped_area to be a problem, something would have to
concurrently allocate a VMA (or dispose of) I think that can't happen at
this point before we even run the binary but yes, better safe than
sorry... I supose the whole patch could get in 2.6.17 even without the
arch_vma_name (that is it can be there, it wont be used though until
your patch gets in).
Ben.
^ permalink raw reply
* undefined symbols of modules
From: Josef Angermeier @ 2006-05-30 7:45 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
when i try to compile my kernel extension as modul, i get some undefined
references. But a look in System.map shows, that the relevant symbols
are defined in the main kernel. Why then those undefined references ?
Any hint is appreciated!
bye
Josef
make ARCH=ppc -C linux modules
make[1]: Entering directory `/scratch-local/esm/linux'
CHK include/linux/version.h
Building modules, stage 2.
MODPOST
*** Warning: "cpm_load_patch" [drivers/usb/host/m82xx-hcd.ko] undefined!
*** Warning: "cpmp" [drivers/usb/host/m82xx-hcd.ko] undefined!
^ permalink raw reply
* Re: undefined symbols of modules
From: Eugene Surovegin @ 2006-05-30 8:06 UTC (permalink / raw)
To: Josef Angermeier; +Cc: linuxppc-embedded
In-Reply-To: <447BF82A.8000503@cs.fau.de>
On Tue, May 30, 2006 at 09:45:46AM +0200, Josef Angermeier wrote:
> Hello,
>
> when i try to compile my kernel extension as modul, i get some undefined
> references. But a look in System.map shows, that the relevant symbols
> are defined in the main kernel. Why then those undefined references ?
Symbol must be exported to be available for modules, just being listed
in System.map isn't enough.
Try adding EXPORT_SYMBOL(...) for those "undefined" references.
--
Eugene
^ permalink raw reply
* Re: [Done] Re: snd-aoa: Sound gone after snd-aoa updates, on PB5,8
From: Michel Dänzer @ 2006-05-30 7:44 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <20060529221730.GA3138@localhost>
On Tue, 2006-05-30 at 00:17 +0200, Wolfgang Pfeiffer wrote:
>=20
> The problem is: with libasound2 1.0.11-6 I cannot even *start*=20
> alsamixer:
>=20
> ------------------------
> $ alsamixer
> ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL default
>=20
> alsamixer: function snd_ctl_open failed for default: No such file or dire=
ctory
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D369478 and friends.
--=20
Earthling Michel D=C3=A4nzer | http://tungstengraphics.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* LXT973 support (dual PHY with single MDIO)
From: Laurent Pinchart @ 2006-05-30 8:48 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm trying to bring up the two ethernet ports on a LXT973 dual-PHY chip. I've
declared two FCC platform devices, which are detected and handled by the
driver/net/fs_enet driver. My issue comes from MDIO support.
The LXT973 has a single MDIO port which answers to two addresses, one for each
PHY. The MDC and MDIO lines are connected to GPIO pins (no PHY interrupt), so
I'm using the bitbang MDIO driver. I've declared a MPC82xx_MDIO_BB platform
device, and set bus_id to "0:00" for both FCC ethernet devices. The first
ethernet device works fine, but the second complains that the PHY is already
in use.
As the PHY read/write accesses are protected by the bus->mdio_lock, I thought
about declaring a second MDIO platform device using the same I/O pins as the
first. Does anybody knows any problem I could run into using that approach ?
Is there a better method to handle the LXT973 MDIO ?
Thanks in advance for any help you can provide.
Best regards,
Laurent Pinchart
^ permalink raw reply
* Re: LXT973 support (dual PHY with single MDIO)
From: Wojciech Kromer @ 2006-05-30 9:05 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200605301048.01209.laurent.pinchart@tbox.biz>
I'm sucesfully using this chip with denx.de 2.4.25 kernel and single
MDIO port.
You need to change auto PHY-addr detection method. By default it
detects both PHYs on same addr.
^ permalink raw reply
* Re: [SOLVED] LXT973 support (dual PHY with single MDIO)
From: Laurent Pinchart @ 2006-05-30 9:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200605301048.01209.laurent.pinchart@tbox.biz>
Hi,
once again, posting to a mailing list helped me solving my problem. It should
have been obvious that the MDIO bus is really a bus, and can as such support
several devices. The issue was that the drivers/net/fs_enet driver set
bus->phy_mask to ~0x9, and the LXT973 uses addresses 0 and 1. Address 1 thus
never got probed. What's the reason for probing addresses 0 and 3 only ?
Laurent Pinchart
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: jourdan @ 2006-05-30 9:39 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <1758.194.3.133.184.1148897976.squirrel@webmail.enib.fr>
>> In message <1402.194.3.133.184.1148888040.squirrel@webmail.enib.fr> you
>> wrote:
>>>
>>> This seems ok to me but I don't have any video signal. My screen
>>> remains
>>> blank.
>>
>> What's your boot arguments? Where is your console device, on the
>> serial port or on the frame buffer?
>
> My boot arguments :
> # more /proc/cmdline
> console=tty0 console=ttyS1,9600 devfs=mount ip=bootp root=/dev/nfs rw
>
> My console is on the serial port (ttyS1 on SMC2).
>
>>> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
>>> ...
>>
>> Did you enable all of the following options in your kernel config?
>>
>> CONFIG_FB=y
>> CONFIG_DUMMY_CONSOLE=y
>> CONFIG_FB_MB86290=y
>> CONFIG_FBCON_ADVANCED=y
>> CONFIG_FBCON_CFB16=y
>> CONFIG_FBCON_FONTS=y
>> CONFIG_FONT_8x8=y
>> CONFIG_FONT_8x16=y
>> CONFIG_VT=y
>> CONFIG_VT_CONSOLE=y
>>
>> My guess is that CONFIG_VT and/or CONFIG_VT_CONSOLE might be missing.
>
> All those options are enabled.
>
As I said earlier, when the driver loads, my monitor don't receive any
video signal. I can force it by calling at the end of the initialization
of the driver :
reg = MB86290FB_READ_DISP_REGISTER(GDC_DISP_REG_EXT_MODE);
MB86290FB_WRITE_DISP_REGISTER(GDC_DISP_REG_EXT_MODE, reg | 0x80010000);
This command enables the display, and "garbage" appears on the monitor.
Then if i do :
# cat /dev/urandom > /dev/fb0
I should see dummy pixels on the screen but in fact nothing happens. This
is still the same garbage on the screen.
I use a custom processor card based on a MPC8270. I can't figure out if
the problem comes from the configuration of my kernel (all the needed
options are enabled) or if it is in the code of the initialisation of my
platform.
This is the first time I try to use framebuffer graphics, so I'm new with
it. Can the framebuffer work from a serial console on a platform without
keyboard ?
Thanks for your help.
^ permalink raw reply
* RE: Linux kernel thread with Linux 2.6.x
From: Laurent Lagrange @ 2006-05-30 9:46 UTC (permalink / raw)
To: 'Thiago Galesi'; +Cc: linuxppc-embedded
In-Reply-To: <82ecf08e0605291013t7bd1627bg92d13908b3d0b7b7@mail.gmail.com>
Hi,
Thanks for your answer, but a tasklet runs in interrupt context
(in_interrupt() != 0) so it doesn't support schedule() call
included in "down" semaphore function.
Any other idea ?
Laurent.
> -----Message d'origine-----
> De : Thiago Galesi [mailto:thiagogalesi@gmail.com]
> Envoyé : lun. 29 mai 2006 18:13
> À : Laurent Lagrange
> Cc : linuxppc-embedded@ozlabs.org
> Objet : Re: Linux kernel thread with Linux 2.6.x
>
>
> >
> > As the interrupt handler can't be scheduled, I have made a
> kernel thread
> > which waits forever on a semaphore.
> > This semaphore is set when a received packet interrupt occured.
>
> You should look into tasklets for this. Not that your system is not
> OK, but, as you said it, it's not fast enough.
>
> Note that you still have some limitations using tasklets, but it's
> more flexible than Interrupt handlers.
>
>
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: jfaslist @ 2006-05-30 10:39 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1148593014.15517.32.camel@basalt.austin.ibm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii; format=flowed, Size: 594 bytes --]
Hi,
So the RTC/NVRAM patch is no longer needed for the Maple?
Thanks
-jf simon
Hollis Blanchard wrote:
>On Fri, 2006-05-19 at 08:58 +1000, Paul Mackerras wrote:
>
>
>>Care to redo the patch?
>>
>>
>
>After some offline discussion, I think we're in agreement that these
>properties are fine, since Linux's device tree code can't handle
>multiple ranges. Right Segher?
>
>
>
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com
^ permalink raw reply
* Re: [Done #2] Re: snd-aoa: Sound gone after snd-aoa updates, on PB5, 8
From: Wolfgang Pfeiffer @ 2006-05-30 11:23 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <1148975072.27856.294.camel@thor.lorrainebruecke.local>
On Tue, May 30, 2006 at 09:44:32AM +0200, Michel Dänzer wrote:
> On Tue, 2006-05-30 at 00:17 +0200, Wolfgang Pfeiffer wrote:
> >
> > The problem is: with libasound2 1.0.11-6 I cannot even *start*
> > alsamixer:
> >
> > ------------------------
> > $ alsamixer
> > ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL default
> >
> > alsamixer: function snd_ctl_open failed for default: No such file or directory
>
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369478 and friends.
Thanks.
And the bug already seems to be fixed with a new version: I just
installed it (libasound2 1.0.11-7) and at least alsamixer and amixer
started without error. Plus: Restarting the KDE sound system after
installing this new version also worked liked a charm.
Thanks to everyone involved :)
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: Segher Boessenkool @ 2006-05-30 11:38 UTC (permalink / raw)
To: jfaslist; +Cc: linuxppc-dev, Paul Mackerras, Hollis Blanchard
In-Reply-To: <447C20C4.50804@yahoo.fr>
> So the RTC/NVRAM patch is no longer needed for the Maple?
> Thanks
> -jf simon
[Post-top not do. Backwards read not do people.]
Hollis' latest patch is needed still. We agreed not to solve it
completely correctly yet, as we'll need more surgery in other parts
of the PowerPC kernel first.
Segher
^ permalink raw reply
* fs_enet segfaults when adding network interface to bridge
From: Laurent Pinchart @ 2006-05-30 11:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I ran into a segfault in the fs_enet driver when adding the network interface
to an ethernet bridge. This only happens when the interface is down.
----- Kernel version -----
Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30 13:25:37 CEST 2006
ppc unknown
(from main linux-2.6 git repository)
----- End of kernel version -----
----- Oops report -----
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C0109884 LR: C010D420 CTR: 00000000
REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-g7f02f290-dirty)
MSR: 00009032 <EE,ME,IR,DR> CR: 24000222 XER: 00000000
DAR: 00000140, DSISR: 20000000
TASK = c0851090[42] 'brctl' THREAD: c027c000
GPR00: C010D414 C027D8A0 C0851090 00000000 C027D8D0 FFFFFFFF F00000A0 EFFFFFFF
GPR08: C026E380 C0210000 00000000 C0230000 C0210000 1001D150 00FFE000 00000001
GPR16: FFFFFFFF 00000000 007FFF00 7FDD0AC0 00000000 10072C94 7FDD0AD8 10072CA4
GPR24: 00000000 10000A48 00000000 C027D8D0 C027D8D0 C08A1A60 C027DC50 C08A1800
NIP [C0109884] phy_ethtool_gset+0x0/0x48
LR [C010D420] fs_get_settings+0x34/0x48
Call Trace:
[C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable)
[C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8
[C027DC40] [C018CBC0] port_cost+0x58/0x108
[C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4
[C027DCE0] [C018D9AC] add_del_if+0x94/0x98
[C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4
[C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404
[C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8
[C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220
[C027DEE0] [C0067164] do_ioctl+0x88/0x9c
[C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0
[C027DF10] [C00675A8] sys_ioctl+0x40/0x74
[C027DF40] [C00040E0] ret_from_syscall+0x0/0x38
Instruction dump:
7c0803a6 4e800020 2f800000 409eff78 4bffffb8 8804000e 2b800001 40bdff70
3860ffea 4bffffd4 61200040 4bffff84 <81230140> 91240004 80030144 90040008
----- End of oops report -----
----- Source lines -----
[C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290)
[C010D414] fs_get_settings+0x28/0x48 (drivers/net/fs_enet/fs_enet-main.c:885)
[C013DDC0] dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122)
[C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54)
----- End of source lines -----
phy_ethtool_gset segfaults when trying to access phydev->supported because
phydev is NULL.
As I'm not familiar with the fs_enet driver, I'm looking for advices regarding
what to fix and how to fix it.
Laurent Pinchart
^ permalink raw reply
* Re: Linux kernel thread with Linux 2.6.x
From: Jörn Engel @ 2006-05-30 11:23 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000a01c683cd$e3f29ca0$5201a8c0@GEG2400>
On Tue, 30 May 2006 11:46:09 +0200, Laurent Lagrange wrote:
>
> Thanks for your answer, but a tasklet runs in interrupt context
> (in_interrupt() != 0) so it doesn't support schedule() call
> included in "down" semaphore function.
Do you have code you can show?
Jörn
--
Data expands to fill the space available for storage.
-- Parkinson's Law
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: jourdan @ 2006-05-30 12:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <2095.194.3.133.184.1148990341.squirrel@webmail.enib.fr>
> Does the 8270 swap bytes on the PCI bus? The CoralP drivers are written
> for
> the 5200, which assumes any PCI card to be little-endian, and thus swaps
> bytes. That is, if you write a 32-bit word, say 0x01020304, the 5200
> PCI
> will actually write 0x04030201. So if 8270 does *not* swap bytes like
> that
> it would be a problem.
>
I checked this and the byte swapping is OK.
^ permalink raw reply
* fs_enet turns promiscous mode off in restart()
From: Laurent Pinchart @ 2006-05-30 12:34 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm having an issue with promiscuous mode in the fs_enet driver. The restart()
function in drivers/net/fs_enet/mac-fcc.c writes to the FPSMR register:
W32(fccp, fcc_fpsmr, FCC_PSMR_ENCRC);
This disable promiscuous mode. Shouldn't set_multicast_list() be called at the
end of restart() to restore promiscuous (and multicast) settings ?
A similar issue exists for the FEC and SCC backends.
Laurent Pinchart
^ permalink raw reply
* Re: [Alsa-devel] [RFC 5/7] snd-aoa: add layout-id fabric
From: Johannes Berg @ 2006-05-30 12:37 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5h64jp9ge4.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On Mon, 2006-05-29 at 14:14 +0200, Takashi Iwai wrote:
> Just from curiosity: Does this work properly?
> I remember that there was a deadlock when you call request_module()
> during module probe.
Yes, it works, but I don't think this is actually done during module
probe (would have to check though)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Johannes Berg @ 2006-05-30 12:43 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5h8xol9gom.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
On Mon, 2006-05-29 at 14:08 +0200, Takashi Iwai wrote:
> > + if (reg != ONYX_REG_CONTROL) {
> > + *value = onyx->cache[reg-FIRSTREGISTER];
> > + return 0;
> > + }
> > + v = i2c_smbus_read_byte_data(&onyx->i2c, reg);
> > + if (v < 0)
> > + return -1;
> > + *value = (u8)v;
> > + onyx->cache[ONYX_REG_CONTROL-FIRSTREGISTER] = *value;
>
> Isn't it "reg - FIRSTREGISTER" ?
Nah, look at the first line I quoted :)
> I'd define a constant for 128.
#define OFFSET_BECAUSE_ALSA_USERSPACE_PROGRAMS_SUCK 128
;)
Just kidding, will do.
> Fold lines to fit with 80 columns (heh, blaming other one's code is
> easy :)
Heh. I thought I'd Lindent'ed most of it.
> > + /* FIXME: we could be checking if anything changed */
> > + mutex_unlock(&onyx->mutex);
> > +
> > + return 1;
>
> The put callback is supposed to return 0 if the values are unchanged
> (although most apps ignore the return value).
Does it have to? This way there's an event, but...
> > +static u8 initial_values[] = {
>
> Should have ARRAY_SIZE(register_map) since this size must be identical
> with register_map.
Good point.
> > +#define ADDCTL(n) \
> > + do { \
> > + ctl = snd_ctl_new1(&n, onyx); \
> > + if (ctl) { \
> > + ctl->id.device = \
> > + onyx->codec.soundbus_dev->pcm->device; \
> > + aoa_snd_ctl_add(ctl); \
>
> No error check?
Hmm, yeah, I guess it should have error checks. Will revisit that.
> Use strlcpy, or MAX_CODEC_NAME_LEN-1. Similar lines are found in
> tas driver too.
Right.
> Looks a bit too hacky. IMO, it's better to define a struct
Maybe I'll just get rid of it completely, it's never hooked up as far as
I know. But yeah, I guess you're right.
> > +static int tas_snd_capture_source_info(struct snd_kcontrol *kcontrol,
> > + struct snd_ctl_elem_info *uinfo)
> > +{
> > + static char* texts[] = { "Line-In", "Microphone" };
>
> char *texts[]
Any particular reason?
> > +/* I need help here!
>
> Use ifdef. Nested comments are bad.
I know. Temporary code, probably going away completely.
> > + aoa_snd_ctl_add(snd_ctl_new1(&volume_control, tas));
>
> Error checks please.
What should it do on such errors?
Thanks,
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [Alsa-devel] [RFC 2/7] snd-aoa: add aoa core
From: Johannes Berg @ 2006-05-30 12:44 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5hac919jzl.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On Mon, 2006-05-29 at 12:57 +0200, Takashi Iwai wrote:
> > + alsa_card = snd_card_new(-1, name, mod, sizeof(struct aoa_card));
>
> Usually the first argument here is the index module option so that
> user may specify the card order (e.g. secondary card) independent from
> the order of module loading.
Are you saying I should add an index module option and pass that?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: Linux kernel thread with Linux 2.6.x
From: almoeli @ 2006-05-30 13:17 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <20060530112343.GB24129@wohnheim.fh-wedel.de>
Hi,
do you have to use the semaphore or does a spinlock also meet your needs?
If you are in kernel 2.4 you can use one of the task_queues (e.g the
scheduler queue, timer and immediate queue also run at irq context) but
that won't have a better speed than your solution because it also gets
the processor when tasks are scheduled (all 10ms I think). In 2.6 it
would be the work_queue (schedule_work()).
So the best way is to use spinlocks and do the work in a tasklet at
interrupt context.
Oliver
Jörn Engel schrieb:
> On Tue, 30 May 2006 11:46:09 +0200, Laurent Lagrange wrote:
>> Thanks for your answer, but a tasklet runs in interrupt context
>> (in_interrupt() != 0) so it doesn't support schedule() call
>> included in "down" semaphore function.
>
> Do you have code you can show?
>
> Jörn
>
^ permalink raw reply
* MPC8270 on Microsys PM827 Kernel 2.6 Oops: kernel access of bad area, sig: 11 [#1]
From: Behre, Frederik - LT @ 2006-05-30 12:46 UTC (permalink / raw)
To: linuxppc-embedded
Hello=20
I compile my kernel with=20
pm82x_deconfig and PCI disabled.
Did I forgot something ??
After error Oops: kernel access of bad area, sig: 11 [#1] the Board
restarts.
Thanks for Helping
Freddy
U-Boot 1.1.4 (May 15 2006 - 09:13:13)
MPC8260 Reset Status: External Soft, External Hard
MPC8260 Clock Configuration
- Bus-to-Core Mult 2.5x, VCO Div 4, 60x Bus Freq 20-60 , Core Freq
50-120
- dfbrg 0, corecnf 0x11, busdf 3, cpmdf 1, plldf 0, pllmf 3, pcidf 3
- vco_out 400000000, scc_clk 100000000, brg_clk 100000000
- cpu_clk 250000000, cpm_clk 200000000, bus_clk 100000000
CPU: MPC8260 (HiP7 Rev 13, Mask 0.1 1K49M) at 250 MHz
Board: PM828
I2C: ready
DRAM: (60x:9COL) 128 MB
FLASH: 32 MB
In: serial
Out: serial
Err: serial
DOC: No DiskOnChip found
Net: FCC1 ETHERNET, FCC2 ETHERNET
BEDBUG:ready
Hit any key to stop autoboot: 0
Using FCC1 ETHERNET device
TFTP from server 192.168.0.1; our IP address is 192.168.0.2
Filename 'uImage-2.6'.
Load address: 0x400000
Loading:
#################################################################
=20
#################################################################
#######################################################
done
Bytes transferred =3D 945041 (e6b91 hex)
## Booting image at 00400000 ...
Image Name: Linux-2.6.14
Created: 2006-05-30 7:59:00 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 944977 Bytes =3D 922.8 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.6.14 (root@c3415) (gcc version 4.0.0 (DENX ELDK 4.0
4.0.0)) #1 Tue May 30 09:58:59 CEST 2006=20
Microsys PM82x PowerPC port=20
Built 1 zonelists Kernel command line: root=3D/dev/nfs rw
nfsroot=3D192.168.0.1:/lop/eldk400/ppc_6xx/ console=3DttyCPM1
ip=3D192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:ppc_82xx::off
panic=3D1
PID hash table entries: 1024 (order: 10, 16384 bytes)=20
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)=20
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 127744k available (1556k kernel code, 384k data, 100k init, 0k
highmem)
Mount-cache hash table entries: 512
softlockup thread 0 started up.
NET: Registered protocol family 16
Generic RTC Driver v1.07
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a80 (irq =3D 4) is a CPM UART
ttyCPM1 at MMIO 0xf0011a90 (irq =3D 5) is a CPM UART
ttyCPM2 at MMIO 0xf0011a00 (irq =3D 40) is a CPM UART
ttyCPM3 at MMIO 0xf0011a20 (irq =3D 41) is a CPM UART
ttyCPM4 at MMIO 0xf0011a40 (irq =3D 42) is a CPM UART
ttyCPM5 at MMIO 0xf0011a60 (irq =3D 43) is a CPM UART=20
io scheduler noop registered=20
io scheduler anticipatory registered=20
io scheduler deadline registered=20
io scheduler cfq registered=20
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize=20
NFTL driver: nftlcore.c $Revision: 1.97 $, nftlmount.c $Revision: 1.40 $
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C0107A14 LR: C0106660 SP: C036FE30 REGS: c036fd80 TRAP: 0300 Not
tainted
MSR: 00003032 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 11
DAR: 00000000, DSISR: 20000000
TASK =3D c0349ae0[1] 'swapper' THREAD: c036e000 Last syscall: 120
GPR00: C036FE38 C036FE30 C0349AE0 C7CD5EE0 C036FE68 00002AA8 C9002AA8
00AA00AA
GPR08: 00AA00AA C036FE40 00009032 00001032 00AA00AA FFFDFFB7 07FFC000
00000001
GPR16: 00800000 07FFF7BC C0180000 00000000 07FF9484 00000000 07FAE1C0
00000001
GPR24: C036FE58 00000000 C7CD5EE0 C01F0000 C7CD5EE0 C01C4BF4 C036FF18
C036FE68
Call trace: [0000000d] [c0106104] [c010637c] [c01011ec] [c01e1ed4]
[c00039e8] [c0006b84] Kernel panic - not syncing: Attempted to kill
init!
<0>Rebooting in 1 seconds..=20
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Takashi Iwai @ 2006-05-30 13:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1148992996.3102.8.camel@johannes>
At Tue, 30 May 2006 14:43:16 +0200,
Johannes Berg wrote:
>
> On Mon, 2006-05-29 at 14:08 +0200, Takashi Iwai wrote:
> > > + if (reg != ONYX_REG_CONTROL) {
> > > + *value = onyx->cache[reg-FIRSTREGISTER];
> > > + return 0;
> > > + }
> > > + v = i2c_smbus_read_byte_data(&onyx->i2c, reg);
> > > + if (v < 0)
> > > + return -1;
> > > + *value = (u8)v;
> > > + onyx->cache[ONYX_REG_CONTROL-FIRSTREGISTER] = *value;
> >
> > Isn't it "reg - FIRSTREGISTER" ?
>
> Nah, look at the first line I quoted :)
Ah, OK it's anyway same...
> > > + /* FIXME: we could be checking if anything changed */
> > > + mutex_unlock(&onyx->mutex);
> > > +
> > > + return 1;
> >
> > The put callback is supposed to return 0 if the values are unchanged
> > (although most apps ignore the return value).
>
> Does it have to? This way there's an event, but...
Yes, in principle. As mentioned, it works even without the check,
though.
> > > +static int tas_snd_capture_source_info(struct snd_kcontrol *kcontrol,
> > > + struct snd_ctl_elem_info *uinfo)
> > > +{
> > > + static char* texts[] = { "Line-In", "Microphone" };
> >
> > char *texts[]
>
> Any particular reason?
Well, I meant the position of asterisk to follow the conventional C
coding style. Of course it should be static.
> > > + aoa_snd_ctl_add(snd_ctl_new1(&volume_control, tas));
> >
> > Error checks please.
>
> What should it do on such errors?
The driver should give up the initialization and fail to load.
Usually the error from snd_ctl_add() is critical, either no memory or
a duplicated control element is found.
Takashi
^ permalink raw reply
* Re: [Alsa-devel] [RFC 2/7] snd-aoa: add aoa core
From: Takashi Iwai @ 2006-05-30 13:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1148993072.3102.10.camel@johannes>
At Tue, 30 May 2006 14:44:31 +0200,
Johannes Berg wrote:
>
> On Mon, 2006-05-29 at 12:57 +0200, Takashi Iwai wrote:
> > > + alsa_card = snd_card_new(-1, name, mod, sizeof(struct aoa_card));
> >
> > Usually the first argument here is the index module option so that
> > user may specify the card order (e.g. secondary card) independent from
> > the order of module loading.
>
> Are you saying I should add an index module option and pass that?
Yep, all other drivers do so.
Takashi
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Johannes Berg @ 2006-05-30 13:26 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5hr72bbqfm.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]
> > > > + return 1;
> > >
> > > The put callback is supposed to return 0 if the values are unchanged
> > > (although most apps ignore the return value).
> >
> > Does it have to? This way there's an event, but...
>
> Yes, in principle. As mentioned, it works even without the check,
> though.
Hmm. I thought it worked like this:
0 -> no change
1 -> change applied, and other apps are notified, 0 returned to the app
-err -> error returned to app
Is that wrong?
> Well, I meant the position of asterisk to follow the conventional C
> coding style. Of course it should be static.
Ah. Yeah, I'll see to that and probably just Lindent the files (cleaning
up after it...)
> The driver should give up the initialization and fail to load.
> Usually the error from snd_ctl_add() is critical, either no memory or
> a duplicated control element is found.
Hmm, that's a bit hard to do since the driver here consists of more than
one module, but I suppose I can do something about it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: fs_enet segfaults when adding network interface to bridge
From: Vitaly Bordug @ 2006-05-30 13:27 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200605301351.11967.laurent.pinchart@tbox.biz>
On Tue, 30 May 2006 13:51:11 +0200
Laurent Pinchart <laurent.pinchart@tbox.biz> wrote:
> Hi everybody,
>
> I ran into a segfault in the fs_enet driver when adding the network interface
> to an ethernet bridge. This only happens when the interface is down.
>
> ----- Kernel version -----
> Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30 13:25:37 CEST 2006
> ppc unknown
> (from main linux-2.6 git repository)
> ----- End of kernel version -----
>
> ----- Oops report -----
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: C0109884 LR: C010D420 CTR: 00000000
> REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-g7f02f290-dirty)
> MSR: 00009032 <EE,ME,IR,DR> CR: 24000222 XER: 00000000
> DAR: 00000140, DSISR: 20000000
> TASK = c0851090[42] 'brctl' THREAD: c027c000
> GPR00: C010D414 C027D8A0 C0851090 00000000 C027D8D0 FFFFFFFF F00000A0 EFFFFFFF
> GPR08: C026E380 C0210000 00000000 C0230000 C0210000 1001D150 00FFE000 00000001
> GPR16: FFFFFFFF 00000000 007FFF00 7FDD0AC0 00000000 10072C94 7FDD0AD8 10072CA4
> GPR24: 00000000 10000A48 00000000 C027D8D0 C027D8D0 C08A1A60 C027DC50 C08A1800
> NIP [C0109884] phy_ethtool_gset+0x0/0x48
> LR [C010D420] fs_get_settings+0x34/0x48
> Call Trace:
> [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable)
> [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8
> [C027DC40] [C018CBC0] port_cost+0x58/0x108
> [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4
> [C027DCE0] [C018D9AC] add_del_if+0x94/0x98
> [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4
> [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404
> [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8
> [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220
> [C027DEE0] [C0067164] do_ioctl+0x88/0x9c
> [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0
> [C027DF10] [C00675A8] sys_ioctl+0x40/0x74
> [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38
> Instruction dump:
> 7c0803a6 4e800020 2f800000 409eff78 4bffffb8 8804000e 2b800001 40bdff70
> 3860ffea 4bffffd4 61200040 4bffff84 <81230140> 91240004 80030144 90040008
> ----- End of oops report -----
>
> ----- Source lines -----
> [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290)
> [C010D414] fs_get_settings+0x28/0x48 (drivers/net/fs_enet/fs_enet-main.c:885)
> [C013DDC0] dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122)
> [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54)
> ----- End of source lines -----
>
> phy_ethtool_gset segfaults when trying to access phydev->supported because
> phydev is NULL.
>
> As I'm not familiar with the fs_enet driver, I'm looking for advices regarding
> what to fix and how to fix it.
>
IIRC, fs_enet got bound to phydev only being ->up. So in down state, phydev may be either null, or last assigned (need to have a look into source to tell for certain). So what is the proper behavior from your point of view?
--
Sincerely,
Vitaly
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox