* Re: Oops: mounting floppy disk on PPC64 (power3)
From: Nathan Lynch @ 2006-03-31 22:50 UTC (permalink / raw)
To: Markus Rothe; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200603312138.16032.markus@unixforces.net>
Hello.
Markus Rothe wrote:
>
> this is kernel 2.6.16.1 compiled with gcc 4.1.0 (gentoo patches). I never
> tried to mount a floppy on this system before, so I don't know if it Oops'ed
> in previous kernel versions, too.
>
> power3 ~ # uname -a
> Linux power3 2.6.16.1 #1 Fri Mar 31 21:08:43 UTC 2006 ppc64 POWER3 (630+) CHRP
> IBM,7044-170 GNU/Linux
> power3 ~ # modprobe floppy
> power3 ~ # mount /mnt/floppy/
> Oops: Kernel access of bad area, sig: 11 [#1]
> NUMA PSERIES
> Modules linked in: floppy
> NIP: C0000000000201E8 LR: D0000000000C43A4 CTR: C0000000000201D8
> REGS: c0000000003df470 TRAP: 0300 Not tainted (2.6.16.1)
> MSR: A000000000001032 <ME,IR,DR> CR: 48000082 XER: 00000000
> DAR: 0000000000000178, DSISR: 0000000040000000
> TASK = c0000000003fc9b0[0] 'swapper' THREAD: c0000000003dc000
> GPR00: C00000000042FC08 C0000000003DF6F0 C0000000004D3310 0000000000000000
> GPR04: C00000000161D000 0000000000000400 0000000000000002 0000000000000750
> GPR08: 0000000000000064 D0000000000D4AE0 D0000000000D5F20 C0000000000201D8
> GPR12: D0000000000CB280 C0000000003FCF80 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 4000000001400000 C0000000003595E0
> GPR20: C0000000003D1F28 00000000017D1A80 C0000000003D1A80 0000000000000060
> GPR24: 00000000000003F0 A000000000009032 0000000000000044 00000000000000D9
> GPR28: 0000000000000400 0000000000000002 D0000000000DB880 C00000000161D000
> NIP [C0000000000201E8] .dma_map_single+0x10/0x70
> LR [D0000000000C43A4] .setup_rw_floppy+0x2c0/0xaa8 [floppy]
> Call Trace:
> [C0000000003DF6F0] [D0000000000C5790] .start_motor+0x108/0x158 [floppy]
> (unreli)
> [C0000000003DF760] [D0000000000C43A4] .setup_rw_floppy+0x2c0/0xaa8 [floppy]
> [C0000000003DF810] [C000000000044714] .run_timer_softirq+0x174/0x20c
> [C0000000003DF8B0] [C00000000003FC68] .__do_softirq+0x80/0x128
> [C0000000003DF940] [C00000000003FD5C] .do_softirq+0x4c/0x68
> [C0000000003DF9C0] [C00000000001C9E8] .timer_interrupt+0x360/0x388
> [C0000000003DFA90] [C0000000000034B8] decrementer_common+0xb8/0x100
> --- Exception: 901 at .ppc64_runlatch_off+0x0/0x50
> LR = .default_idle+0x48/0x70
> [C0000000003DFD80] [C000000000016764] .default_idle+0x68/0x70 (unreliable)
> [C0000000003DFE00] [C0000000000166E8] .cpu_idle+0x40/0x54
> [C0000000003DFE70] [C0000000000092B0] .rest_init+0x3c/0x54
> [C0000000003DFEF0] [C0000000003B16D4] .start_kernel+0x1f0/0x208
> [C0000000003DFF90] [C000000000008514] .start_here_common+0x88/0x174
> Instruction dump:
> 4e800421 e8410028 48000008 0fe00000 38210070 e8010010 7c0803a6 4e800020
> 7c0802a6 f8010010 f821ff91 e80298d0 <e9230178> 7fa90000 409e000c e92298d8
>
> Am I doing something wrong?
Nope.
I believe this was fixed in Linus' tree as of a couple days ago:
diff-tree b239cbe957ae730caa8af2f169a4d35b8c1bb299 (from
69ed3324983bb937d78a857Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue Mar 28 14:40:58 2006 +1100
[PATCH] powerpc: make ISA floppies work again
We used to assume that a DMA mapping request with a NULL dev was
for
ISA DMA. This assumption was broken at some point. Now we
explicitly
pass the detected ISA PCI device in the floppy setup.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Maybe you could verify with latest -git, or 2.6.17-rc1 when it's
released?
^ permalink raw reply
* Re: [ck] Re: Staircase test patch
From: Con Kolivas @ 2006-03-31 23:17 UTC (permalink / raw)
To: ck; +Cc: Thorsten Will, linux list
In-Reply-To: <20060331213106.GA6905@lliwnetsroht.news.arcor.de>
On Saturday 01 April 2006 07:31, Thorsten Will wrote:
> On Friday 31 March 2006 23:07 +1000, Con Kolivas wrote:
> >Hi Thorsten et al
>
> Hi, Con.
>
> >Thorsten could you please test to see if this fixes the problem for you?
>
> Oh boy, oh boy, oh boy.
>
> Against a bash loop:
> |# dd bs=1M count=2048 </dev/hdb >/dev/null
> |2048+0 records in
> |2048+0 records out
> |2147483648 bytes transferred in 35.497603 seconds (60496582 bytes/sec)
>
> Yes! Success! And the crowd goes wild! :-)
>
> I think you finally nailed it. Thank you so much!
No, thank _you_ for bringing it to my attention and testing :)
Cheers,
Con
^ permalink raw reply
* Re: [PATCH] splice exports
From: Jeff Garzik @ 2006-03-31 23:14 UTC (permalink / raw)
To: Jens Axboe; +Cc: Arjan van de Ven, Andrew Morton, Linus Torvalds, linux-kernel
In-Reply-To: <20060331183617.GD14022@suse.de>
Jens Axboe wrote:
> On Fri, Mar 31 2006, Jeff Garzik wrote:
>> Jens Axboe wrote:
>>> On Fri, Mar 31 2006, Arjan van de Ven wrote:
>>>> On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
>>>>> Woe be unto he who builds their filesystems as modules.
>>>> since splice support is highly linux specific and new.. shouldn't these
>>>> be _GPL exports?
>>> Yes they should, I'll add that to the current splice tree.
>> Why? We don't usually restrict filesystems in such ways... I would
>> rather a binary-only module reference generic_file_splice_read() than
>> create its own.
>
> You could use that very same argument for any piece of the kernel, then,
> so I don't think that adds much value to _not_ exporting it GPL.
Not really, because I'm considering the Real World(tm) users, not
abstract theory :) The other filesystem junk is exported non-GPL, and
existing binary-only filesystems use that stuff.
IOW its a bit rude to say "oh you can have your BO filesystem, just not
splice support."
Jeff
^ permalink raw reply
* Re: [RESEND][2.6.15] New ATA error messages on upgrade to 2.6.15
From: Kyle Moffett @ 2006-03-31 23:13 UTC (permalink / raw)
To: Eric D. Mudama
Cc: LKML Kernel, Bartlomiej Zolnierkiewicz, Alan Cox, linux-ide,
Andrew Morton
In-Reply-To: <311601c90603311421g7241cb78m300aaaf423fae3ff@mail.gmail.com>
On Mar 31, 2006, at 17:21:16, Eric D. Mudama wrote:
> can you please post your dmesg?
Dmesg below. Thanks for taking a look!
Cheers,
Kyle Moffett
Total memory = 832MB; using 2048kB for hash table (at c0400000)
Linux version 2.6.15-1-powerpc (Debian 2.6.15-3) (horms@verge.net.au)
(gcc version 4.0.3 20060115 (prerelease) (Debian 4.0.2-7)) #2 Thu Jan
19 03:51:42 UTC 2006
Found UniNorth memory controller & host bridge, revision: 7
Mapped at 0xfdf00000
Found a Keylargo mac-io controller, rev: 2, mapped at 0xfde80000
Processor NAP mode on idle enabled.
PowerMac motherboard: PowerMac G4 AGP Graphics
Found UniNorth PCI host bridge at 0xf0000000. Firmware bus number: 0->0
Found UniNorth PCI host bridge at 0xf2000000. Firmware bus number: 0->1
Found UniNorth PCI host bridge at 0xf4000000. Firmware bus number: 0->0
via-pmu: Server Mode is disabled
PMU driver 2 initialized for Core99, firmware: 0c
nvram: Checking bank 0...
nvram: gen0=366, gen1=367
nvram: Active bank is: 1
nvram: OF partition at 0x210
nvram: XP partition at 0x1220
nvram: NR partition at 0x1320
On node 0 totalpages: 212992
DMA zone: 196608 pages, LIFO batch:31
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 0 pages, LIFO batch:0
HighMem zone: 16384 pages, LIFO batch:3
Built 1 zonelists
Kernel command line: root=/dev/mapper/raid-root ro
PowerMac using OpenPIC irq controller at 0x80040000
OpenPIC Version 1.2 (4 CPUs and 64 IRQ sources) at fc62e000
OpenPIC timer frequency is 4.166666 MHz
PID hash table entries: 4096 (order: 12, 65536 bytes)
GMT Delta read from XPRAM: 0 minutes, DST: off
time_init: decrementer frequency = 24.907667 MHz
Console: colour dummy device 80x25
serial8250_console_init: nothing to do on PowerMac
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 835136k available (2172k kernel code, 944k data, 172k init,
65536k highmem)
AGP special page: 0xeffff000
Calibrating delay loop... 794.62 BogoMIPS (lpj=397312)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
device-tree: property "l2-cache" name conflicts with node in /cpus/
PowerPC,G4@0
checking if image is initramfs... it is
Freeing initrd memory: 3260k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Enabling device 0001:11:02.0 (0004 -> 0007)
Registering openpic with sysfs...
Thermal assist unit using timers, shrink_timer: 2000 jiffies
audit: initializing netlink socket (disabled)
audit(1141624084.107:1): initialized
highmem bounce pool size: 64 pages
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
PCI: Enabling device 0000:00:10.0 (0086 -> 0087)
aty128fb: Invalid ROM signature 1111 should be 0xaa55
aty128fb: BIOS not located, guessing timings.
aty128fb: Rage128 PF PRO AGP [chip rev 0x1] 16M 128-bit SDR SGRAM (1:1)
Console: switching to colour frame buffer device 128x48
fb0: ATY Rage128 frame buffer device on Rage128 PF PRO AGP
Generic RTC Driver v1.07
Macintosh non-volatile memory driver v1.1
serial8250_init: nothing to do on PowerMac
pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
ttyS0 at MMIO 0x80013020 (irq = 22) is a Z85c30 ESCC - Serial port
ttyS1 at MMIO 0x80013000 (irq = 50) is a Z85c30 ESCC - Serial port
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
MacIO PCI driver attached to Keylargo chipset
input: Macintosh mouse button emulation as /class/input/input0
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
adb: starting probe task...
adb: finished probe task...
ide0: Found Apple KeyLargo ATA-4 controller, bus ID 2, irq 19
Probing IDE interface ide0...
hda: ST380011A, ATA DISK drive
hda: Enabling Ultra DMA 4
ide0 at 0xf100e000-0xf100e007,0xf100e160 on irq 19
ide1: Found Apple KeyLargo ATA-3 controller, bus ID 0, irq 20
Probing IDE interface ide1...
hdc: CD-ROM Drive/F5A, ATAPI CD/DVD-ROM drive
hdc: Disabling (U)DMA for CD-ROM Drive/F5A (blacklisted)
ide1 at 0xf1016000-0xf1016007,0xf1016160 on irq 20
ide2: Found Apple KeyLargo ATA-3 controller, bus ID 1, irq 21
Probing IDE interface ide2...
mice: PS/2 mouse device common for all mice
Found KeyWest i2c on "uni-n", 2 channels, stepping: 4 bits
Found KeyWest i2c on "mac-io", 1 channel, stepping: 4 bits
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 172k init
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected Apple UniNorth chipset
agpgart: configuring for size idx: 4
agpgart: AGP aperture is 16M @ 0x0
PDC20268: IDE controller at PCI slot 0001:11:02.0
PDC20268: chipset revision 2
PDC20268: ROM enabled at 0x80090000
PDC20268: 100%% native mode on irq 52
ide3: BM-DMA at 0x1400-0x1407, BIOS settings: hdg:pio, hdh:pio
ide4: BM-DMA at 0x1408-0x140f, BIOS settings: hdi:pio, hdj:pio
Probing IDE interface ide3...
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver
(PCI)
hdg: Maxtor 6Y080P0, ATA DISK drive
ide3 at 0x1440-0x1447,0x1432 on irq 52
Probing IDE interface ide4...
hdi: SAMSUNG SP0822N, ATA DISK drive
ide4 at 0x1420-0x1427,0x1412 on irq 52
r8169 Gigabit Ethernet driver 2.2LK loaded
PCI: Enabling device 0001:11:03.0 (0014 -> 0017)
eth0: Identified chip type is 'RTL8169s/8110s'.
eth0: RTL8169 at 0xf1060000, 00:08:54:d1:af:f9, IRQ 53
sungem.c:v0.98 8/24/03 David S. Miller (davem@redhat.com)
PCI: Enabling device 0001:11:08.0 (0000 -> 0002)
ohci_hcd 0001:11:08.0: OHCI Host Controller
ohci_hcd 0001:11:08.0: new USB bus registered, assigned bus number 1
ohci_hcd 0001:11:08.0: irq 27, io mem 0x80083000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
PHY ID: 406212, addr: 0
eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:30:65:96:77:a4
eth0: Found BCM5201 PHY
PCI: Enabling device 0001:11:09.0 (0000 -> 0002)
ohci_hcd 0001:11:09.0: OHCI Host Controller
ohci_hcd 0001:11:09.0: new USB bus registered, assigned bus number 2
ohci_hcd 0001:11:09.0: irq 28, io mem 0x80082000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
usb 2-1: new full speed USB device using ohci_hcd and address 2
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 3 ports detected
usb 2-1.1: new full speed USB device using ohci_hcd and address 3
usbcore: registered new driver hiddev
eth_pub: Link is up at 100 Mbps, full-duplex.
drivers/usb/input/hid-core.c: timeout initializing reports
input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/
input1
input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB
Keyboard] on usb-0001:11:09.0-1.1
input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/
input2
input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB
Keyboard] on usb-0001:11:09.0-1.1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
usbcore: registered new driver yealink
drivers/usb/input/yealink.c: Yealink phone driver:yld-20050816
hda: max request size: 1024KiB
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63,
UDMA(66)
hda: cache flushes supported
hda: [mac] hda1 hda2 hda3 hda4 hda5
hdg: max request size: 128KiB
hdg: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63,
UDMA(100)
hdg: cache flushes supported
hdg:hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
PDC202XX: Primary channel reset.
ide3: reset: success
[mac] hdg1 hdg2 hdg3 hdg4 hdg5
hdi: max request size: 1024KiB
hdi: 156368016 sectors (80060 MB) w/2048KiB Cache, CHS=16383/255/63,
UDMA(33)
hdi: cache flushes supported
hdi: [mac] hdi1 hdi2 hdi3 hdi4 hdi5
hdc: ATAPI 48X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.20
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
md: raid1 personality registered as nr 3
raid5: measuring checksumming speed
8regs : 488.000 MB/sec
8regs_prefetch: 408.000 MB/sec
32regs : 448.000 MB/sec
32regs_prefetch: 392.000 MB/sec
raid5: using function: 8regs (488.000 MB/sec)
md: raid5 personality registered as nr 4
md: md0 stopped.
md: bind<hda3>
md: bind<hdi3>
md: bind<hdg3>
raid1: raid set md0 active with 3 out of 3 mirrors
md: md1 stopped.
md: bind<hda4>
md: bind<hdi4>
md: bind<hdg4>
raid5: device hdg4 operational as raid disk 0
raid5: device hdi4 operational as raid disk 2
raid5: device hda4 operational as raid disk 1
raid5: allocated 3168kB for md1
raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 2
RAID5 conf printout:
--- rd:3 wd:3 fd:0
disk 0, o:1, dev:hdg4
disk 1, o:1, dev:hda4
disk 2, o:1, dev:hdi4
md: md2 stopped.
md: bind<hda5>
md: bind<hdi5>
md: bind<hdg5>
raid5: device hdg5 operational as raid disk 0
raid5: device hdi5 operational as raid disk 2
raid5: device hda5 operational as raid disk 1
raid5: allocated 3168kB for md2
raid5: raid level 5 set md2 active with 3 out of 3 devices, algorithm 2
RAID5 conf printout:
--- rd:3 wd:3 fd:0
disk 0, o:1, dev:hdg5
disk 1, o:1, dev:hda5
disk 2, o:1, dev:hdi5
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
cdrom: open failed.
hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
PDC202XX: Primary channel reset.
ide3: reset: success
Adding 1048440k swap on /dev/md1. Priority:-1 extents:1 across:1048440k
EXT3-fs warning: maximal mount count reached, running e2fsck is
recommended
EXT3 FS on dm-0, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on md0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-4, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
input: PowerMac Beep as /class/input/input3
NET: Registered protocol family 15
eth_pub: Link is up at 100 Mbps, full-duplex.
eth_pub: Pause is disabled
r8169: eth_lan: link up
ip_tables: (C) 2000-2002 Netfilter core team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (6656 buckets, 53248 max) - 232 bytes per
conntrack
ClusterIP Version 0.8 loaded successfully
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. http://
snowman.net/projects/ipt_recent/
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery
directory
NFSD: recovery directory /var/lib/nfs/v4recovery doesn't exist
NFSD: starting 90-second grace period
Initializing IPsec netlink socket
eth_pub: no IPv6 routers present
eth_lan: no IPv6 routers present
eth_pub: Link is up at 100 Mbps, full-duplex.
eth_pub: Pause is disabled
tun_624: Disabled Privacy Extensions
GRE over IPv4 tunneling driver
hdi: dma_timer_expiry: dma status == 0x21
hdi: DMA timeout error
hdi: dma timeout error: status=0xd0 { Busy }
ide: failed opcode was: unknown
hdi: DMA disabled
PDC202XX: Secondary channel reset.
ide4: reset: success
[... ad nauseum ...]
^ permalink raw reply
* 2.6.16.1 (1) vs ieee1394 (0) HELP! (I told the missus I could do this)
From: Gene Heskett @ 2006-03-31 23:12 UTC (permalink / raw)
To: linux kernel mailing list
Greetings all;
I may have found a gotcha in the 2.6.16.1 and NDI how far back it goes
because I haven't used anything ieee1394 in months.
Anyway, I plugged in my camera, a Sony DCR-TVR460 and fired up kino,
fully expecting to see the viewfinders image on screen as soon as I
switched kino to the capture screen.
Unforch, its blank and kino is locked up, needing kde's emergency kill
the process to kill it when I click on the closing x.
>From the logs, I get this is 4 or 5 lines.
Mar 31 17:30:16 coyote ieee1394.agent[8925]: ... no drivers for IEEE1394
product 0x/0x/0x
Mar 31 17:30:16 coyote ieee1394.agent[8921]: ... no drivers for IEEE1394
product 0x/0x/0x
Mar 31 17:30:16 coyote kernel: ieee1394: raw1394: /dev/raw1394 device
initialized
And about 6 or 7 lines of gconf verbosy later, this:
Mar 31 17:31:28 coyote kernel: ohci1394: fw-host0: Waking dma ctx=0 ...
processing is probably too slow
then:
[root@coyote linux-2.6.16.1]# lsmod |grep 1394
raw1394 24172 0
dv1394 16716 0
ohci1394 27824 1 dv1394
ieee1394 82488 3 raw1394,dv1394,ohci1394
And:
[root@coyote linux-2.6.16.1]#
ls /lib/modules/2.6.16.1/kernel/drivers/ieee1394
dv1394.ko ieee1394.ko ohci1394.ko raw1394.ko sbp2.ko video1394.ko
sbp2.ko isn't needed, its for a webcam thats a POS. I should quit
building it altogether.
modprobe video1394 inserts that module, but makes zilch difference.
kino still freezes the instant the capture button is clicked.
Unplugging the firewire cable from the camera is silent in messages, but
dmesg says:
ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[08004601044684e4]
ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[08004601044684e4]
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[08004601044684e4]
ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[08004601044684e4]
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
Then from:
[root@coyote boot]# lspci -vv |grep -A10 01:09
01:09.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23
IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (500ns min, 1000ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 12
Region 0: Memory at ec004000 (32-bit, non-prefetchable)
Region 1: Memory at ec000000 (32-bit, non-prefetchable)
[size=16K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
And I'm not smart enough for anything there to raise a flag.
So obviously something's gone aglay, but what?
The last time I ran this config to do some movie editing of a wedding,
along about June of last year, it all Just Worked. And I recently did
some much needed housekeeping, such that if I wanted to build a 2.6.14
kernel, I'd have to go get the tarball & start from scratch.
Ideas anybody?
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply
* Re: [PATCH] IPoIB queue size tune patch
From: Roland Dreier @ 2006-03-31 20:44 UTC (permalink / raw)
To: Shirley Ma; +Cc: linux-kernel, openib-general
In-Reply-To: <OFC9A94743.F4C78DFE-ON87257142.005F70AF-88257142.006068A0@us.ibm.com>
> +static int expsize(int size)
> +{
> + int expsize_t = 1;
> + int j = 1;
> + while (size / 2 >= expsize_t) {
> + expsize_t = 1 << ++j;
> + }
> + return expsize_t;
> +}
Yikes... is this just a very hard-to-understand version of roundup_pow_of_two()?
Hmm, no, it's rounding down I guess. But is there any reason not to
use roundup_pow_of_two() instead?
- R.
^ permalink raw reply
* Re: [PATCH 2/2] Base pSeries PCIe support
From: Olof Johansson @ 2006-03-31 23:08 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060331224858.GC952@pb15.lixom.net>
On Fri, Mar 31, 2006 at 04:48:58PM -0600, Olof Johansson wrote:
> > + dn->intrs = prom_alloc(dn->n_intrs * sizeof(*(dn->intrs)), mem_start);
> > + if (!dn->intrs) {
> > + printk(KERN_EMERG "finish_msi_node: can't allocate space\n");
> > + return;
> > + }
> > +
> > + if (measure_only)
> > + return;
>
> You probably want to return from measure_only _before_ you allocate and
> populate intrs...
Nevermind, this is correct as-is.
-Olof
^ permalink raw reply
* [linux-lvm] lvm2 recovery issue
From: Catalin Constantin @ 2006-03-31 23:04 UTC (permalink / raw)
To: linux-lvm
Hi there,
I am using lvm2 on debian.
The lvm was build on top of 2 software raid partitions:
/dev/md2 and /dev/md3
/dev/md3 was a raid 1 partition built from
/dev/sdc1 and /dev/sdd1
The partition type is xfs. (both raids /dev/md2, /dev/md3 and lvm
storage).
Now, the problem i have.
Somehow the /dev/md3 partition got messed up (out of sync) and between
reboots the lvm partition uses alternatively either
/dev/sdc1 or /dev/sdd1
eg:
pvdisplay
Found duplicate PV VxRU9BoOAwLDxJ8yifZT2fJGEn8CeLvs: using /dev/sdd1 not /dev/sdc1
--- Physical volume ---
PV Name /dev/md2
VG Name vg
PV Size 100.50 GB / not usable 0
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 25727
Free PE 0
Allocated PE 25727
PV UUID 1vtRnR-jmjP-zbgG-JZJs-1WJu-3ZyV-Vik6wH
--- Physical volume ---
PV Name /dev/sdc1
VG Name vg
PV Size 130.39 GB / not usable 0
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 33381
Free PE 0
Allocated PE 33381
PV UUID VxRU9B-oOAw-LDxJ-8yif-ZT2f-JGEn-8CeLvs
The bad thing is that some files ended up on /dev/sdd1 and some others
on /dev/sdc1.
I've unmounted the storage lvm drive and tryed to do a /dev/md3
Assemble but it looks like it won't come up !
mdadm --detail /dev/md3
mdadm: md device /dev/md3 does not appear to be active.
mdadm -A /dev/md3
mdadm: no devices found for /dev/md3
mdadm -A /dev/md3 /dev/sdd1
mdadm: /dev/md3 assembled from 1 drive - need all 2 to start it (use --run to insist).
mdadm -A /dev/md3 /dev/sdd1 /dev/sdc1
mdadm: failed to add /dev/sdc1 to /dev/md3: Device or resource busy
mdadm: /dev/md3 assembled from 1 drive - need all 2 to start it (use --run to insist).
I've already did a backup of what i can mount now.
Some files are still on the "other lvm".
What i need to know are some advices from you guys of how to recover
the most of the data from the "mess" i ended up with !
Eg:
- start lvm with /dev/sdd1 and do another backup (how do i do it in
order to make the damage minimum)
- start the md3 (repair or some) and not to loose data
Anything you can come up will be highly appreciated.
Thank you for your time and sorry if the post is too big!
--
Catalin Constantin
Bounce Software
^ permalink raw reply
* [ALSA - driver 0001987]: Upmix Feature Request
From: bugtrack @ 2006-03-31 23:03 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1987>
======================================================================
Reported By: the-me
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1987
Category: CORE - control
Reproducibility: always
Severity: feature
Priority: normal
Status: feedback
Distribution: Debian
Kernel Version: 2.6.16.1
======================================================================
Date Submitted: 03-31-2006 20:38 CEST
Last Modified: 04-01-2006 01:03 CEST
======================================================================
Summary: Upmix Feature Request
Description:
Hi,
I, and many users more, want a feature at the alsamixer, called Upmix.
I've got an Terratec Aureon 5.1 Fun and I tried many things, but it's not
able, that I can hear an mp3 with upmixed 5.1 sound. Here is my actual
.asoundrc:
pcm.ch51upmix {
type route
slave.pcm surround51
slave.channels 6
ttable.0.0 1
ttable.1.1 1
ttable.0.2 1
ttable.1.3 1
ttable.0.4 0.5
ttable.1.4 0.5
ttable.0.5 0.5
ttable.1.5 0.5
}
pcm.!default
{
type plug
slave.pcm ch51upmix
}
pcm.lowpass {
type ladspa
path "/usr/lib/ladspa"
plugins [ {
label lpf
input {
controls [ 50 ]
}
} ]
}
With this .asoundrc, all speakers work, but my subwoofer doesn't play only
low frequen...
Can you please add such a feature?
Greetz, Patrick
======================================================================
----------------------------------------------------------------------
the-me - 03-31-06 21:15
----------------------------------------------------------------------
But I need upmixing, no real Surroundsound.
And I dont know, how to use this lists :/
----------------------------------------------------------------------
Raymond - 04-01-06 01:03
----------------------------------------------------------------------
Have you try the alsa-plugin ?
http://cvs.sourceforge.net/viewcvs.py/*checkout*/alsa/alsa-plugins/doc/upmix.txt?rev=1.1
Issue History
Date Modified Username Field Change
======================================================================
03-31-06 20:38 the-me New Issue
03-31-06 20:38 the-me Distribution => Debian
03-31-06 20:38 the-me Kernel Version => 2.6.16.1
03-31-06 20:40 the-me Note Added: 0009048
03-31-06 21:02 rlrevell Status new => closed
03-31-06 21:02 rlrevell Note Added: 0009049
03-31-06 21:15 the-me Status closed => feedback
03-31-06 21:15 the-me Resolution open => reopened
03-31-06 21:15 the-me Note Added: 0009050
04-01-06 01:03 Raymond Note Added: 0009052
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [lm-sensors] [PATCH 2.6] scx200_acb: Use PCI I/O resource when
From: Jordan Crouse @ 2006-03-31 23:03 UTC (permalink / raw)
To: linux-kernel; +Cc: lm-sensors, info-linux, BGardner
The CS5535 and CS5536 both define the I/O base for the SMBUS device in a
PCI header. This patch uses that header for the I/O base rather then
using the MSR backdoor.
This patch isn't as urgent as the other one, so it can probably take the
usual trip up through Greg's tree.
--
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>
-------------- next part --------------
[PATCH] scx200_acb: Use PCI I/O resource when appropriate
From: Jordan Crouse <jordan.crouse at amd.com>
On the CS5535 and CS5536, the I/O resource is allocated through PCI,
so use that instead of using the MSR backdoor.
Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>
---
drivers/i2c/busses/scx200_acb.c | 114 +++++++++++++++++++++++++++------------
1 files changed, 78 insertions(+), 36 deletions(-)
diff --git a/drivers/i2c/busses/scx200_acb.c b/drivers/i2c/busses/scx200_acb.c
index e7a2225..454492f 100644
--- a/drivers/i2c/busses/scx200_acb.c
+++ b/drivers/i2c/busses/scx200_acb.c
@@ -33,7 +33,6 @@
#include <linux/delay.h>
#include <linux/mutex.h>
#include <asm/io.h>
-#include <asm/msr.h>
#include <linux/scx200.h>
@@ -85,6 +84,10 @@ struct scx200_acb_iface {
u8 *ptr;
char needs_reset;
unsigned len;
+
+ /* PCI device info */
+ struct pci_dev *pdev;
+ int bar;
};
/* Register Definitions */
@@ -417,7 +420,8 @@ static int scx200_acb_probe(struct scx20
return 0;
}
-static int __init scx200_acb_create(const char *text, int base, int index)
+static int __init scx200_acb_create(char *text, unsigned int base, int index,
+ struct pci_dev *pdev, int bar)
{
struct scx200_acb_iface *iface;
struct i2c_adapter *adapter;
@@ -444,13 +448,31 @@ static int __init scx200_acb_create(con
snprintf(description, sizeof(description), "%s ACCESS.bus [%s]",
text, adapter->name);
- if (request_region(base, 8, description) = 0) {
- printk(KERN_ERR NAME ": can't allocate io 0x%x-0x%x\n",
- base, base + 8-1);
- rc = -EBUSY;
- goto errout_free;
+ if (pdev != NULL) {
+
+ iface->pdev = pdev;
+ iface->bar = bar;
+
+ pci_enable_device_bars(iface->pdev, 1 << iface->bar);
+
+ if (pci_request_region(iface->pdev, iface->bar, description)) {
+ printk(KERN_ERR NAME ": can't allocate PCI region %d\n",
+ iface->bar);
+ rc = -EBUSY;
+ goto errout_free;
+ }
+
+ iface->base = pci_resource_start(iface->pdev, iface->bar);
+ } else {
+ if (request_region(base, 8, description) = 0) {
+ printk(KERN_ERR NAME ": can't allocate io 0x%x-0x%x\n",
+ base, base + 8 - 1);
+ rc = -EBUSY;
+ goto errout_free;
+ }
+
+ iface->base = base;
}
- iface->base = base;
rc = scx200_acb_probe(iface);
if (rc) {
@@ -474,7 +496,11 @@ static int __init scx200_acb_create(con
return 0;
errout_release:
- release_region(iface->base, 8);
+ if (iface->pdev != NULL)
+ pci_release_region(iface->pdev, iface->bar);
+ else
+ release_region(iface->base, 8);
+
errout_free:
kfree(iface);
errout:
@@ -487,49 +513,60 @@ static struct pci_device_id scx200[] = {
{ },
};
-static struct pci_device_id divil_pci[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_CS5535_ISA) },
- { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_ISA) },
- { } /* NULL entry */
+/* On the CS5535 and CS5536, the SMBUS I/0 base is a PCI resource, so
+ we should allocate that resource through the PCI
+ subsystem. rather then going through the MSR back door.
+*/
+
+static struct {
+ unsigned int vendor;
+ unsigned int device;
+ char *name;
+ int bar;
+} divil_pci[] = {
+ {
+ PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_CS5535_ISA, "CS5535", 0}, {
+ PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_ISA, "CS5536", 0}
};
-#define MSR_LBAR_SMB 0x5140000B
+#define DIVIL_LENGTH (sizeof(divil_pci) / sizeof(divil_pci[0]))
static int scx200_add_cs553x(void)
{
- u32 low, hi;
- u32 smb_base;
-
- /* Grab & reserve the SMB I/O range */
- rdmsr(MSR_LBAR_SMB, low, hi);
+ int dev;
+ struct pci_dev *pdev;
- /* Check the IO mask and whether SMB is enabled */
- if (hi != 0x0000F001) {
- printk(KERN_WARNING NAME ": SMBus not enabled\n");
- return -ENODEV;
+ for (dev = 0; dev < DIVIL_LENGTH; dev++) {
+ pdev + pci_find_device(divil_pci[dev].vendor,
+ divil_pci[dev].device, NULL);
+ if (pdev != NULL)
+ break;
}
- /* SMBus IO size is 8 bytes */
- smb_base = low & 0x0000FFF8;
+ if (pdev = NULL)
+ return -ENODEV;
- return scx200_acb_create("CS5535", smb_base, 0);
+ return scx200_acb_create(divil_pci[dev].name, 0, 0, pdev,
+ divil_pci[dev].bar);
}
static int __init scx200_acb_init(void)
{
int i;
- int rc = -ENODEV;
+ int rc = -ENODEV;
pr_debug(NAME ": NatSemi SCx200 ACCESS.bus Driver\n");
- /* Verify that this really is a SCx200 processor */
- if (pci_dev_present(scx200)) {
- for (i = 0; i < MAX_DEVICES; ++i) {
- if (base[i] > 0)
- rc = scx200_acb_create("SCx200", base[i], i);
- }
- } else if (pci_dev_present(divil_pci))
- rc = scx200_add_cs553x();
+ /* If this is a CS5535 or CS5536, then probe the PCI header */
+
+ if (!pci_dev_present(scx200))
+ return scx200_add_cs553x();
+
+ for (i = 0; i < MAX_DEVICES; ++i) {
+ if (base[i] > 0)
+ rc = scx200_acb_create("SCx200", base[i], i, NULL, 0);
+ }
return rc;
}
@@ -544,7 +581,12 @@ static void __exit scx200_acb_cleanup(vo
up(&scx200_acb_list_mutex);
i2c_del_adapter(&iface->adapter);
- release_region(iface->base, 8);
+
+ if (iface->pdev != NULL)
+ pci_release_region(iface->pdev, iface->bar);
+ else
+ release_region(iface->base, 8);
+
kfree(iface);
down(&scx200_acb_list_mutex);
}
^ permalink raw reply related
* Re: accessed/dirty bit handler tuning
From: Zoltan Menyhart @ 2006-03-31 22:57 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <44157CF1.5060902@bull.net>
Chen, Kenneth W wrote:
> You are correct. I forgot that nested_dtlb_miss doesn't actually do the check.
> I rather prefer not to add anything in the fast path to detect an exceedingly
> rare race event (only if ia64 architect screwed up so bad that made itc.d have
> 10,000 cycle latency and at the same time does a splendid job at job at ptc.g
> which completes in zero cycle along with other thousands of other instructions).
>
> In that event, as I said, it's actually better to simple purge the entry, write
> the dirty bit into in-memory page table entry and let the hardware page walker
> insert the new entry.
My first guess is:
- keep the fast path as it is (we are in virtual mode)
- after a nested DTLB fault, we do not return return to the fast path in physical
but to the "completed" dirty bit fault handler
I guess it is more efficient than to let the hardware page walker
insert the new entry (we already have it in a register).
I'll have to think it over. I'm not sure we can write anything after the
nested DTLB fault. The next example:
cpu0: cpu1: cpu2:
dirty bit fault:
attempts to read the PTE
nested DTLB fault:
walks page table
back to dirty bit handler:
(keeps the physical address
of the PTE in r17)
free_pgtables:
ptc.g dirty bit fault address
free the data page
ptc.g PTE page address
free the PTE page
page_alloc:
re-uses the old PTE page
(still keeps the physical address
of the PTE whose page has gone)
ld
or
cmpxchg
Probably, there is no way to make sure the physical address of the PTE
remains valid => we have to switch back to virtual mode for the "completed"
dirty bit fault handler.
> Can you do some stress test experiments and let us know how many time ptc.l
> was actually executed in vhpt_miss/tlb_miss/dirty/access
> handler? Thanks.
Well, to instrument the kernel may take some time...
What stress test program do you think of?
Zoltan
^ permalink raw reply
* Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4
From: Fabian Knittel @ 2006-03-31 22:52 UTC (permalink / raw)
To: linux-ide; +Cc: Christiaan den Besten, Jeff Garzik, milan
In-Reply-To: <011f01c639f9$8dc86bc0$3d64880a@speedy>
Hi all,
correct me if I'm wrong, but apparently this issue hasn't been taken
care of yet and I've only seen reports of "wrong wiring" ... where
everyone apart from the current linux driver sees correct wiring.
In other words: The boards appear to be wired correctly (or maybe just
uniformly the wrong way) and the bios, the windows driver and the closed
source promise driver (reportedly) know how to handle it.
We have a SATA 150 TX4 board with the same behaviour and would love to
see this annoying little bug fixed in linux. :)
Fabian
[ More context for reference. (No new text below.) ]
Christiaan den Besten wrote:
> We have several of these boards in use [SATA 300 TX4] (bought over time
> .. not in one batch). All of them have the ordering as described below.
> So another vote for "Please fix!" :)
>
> ----- Original Message ----- From: "Eyal Lebedinsky" <eyal@eyal.emu.id.au>
> To: "Milan Kupcevic" <milan@physics.harvard.edu>
> Cc: "Jeff Garzik" <jgarzik@pobox.com>; <linux-ide@vger.kernel.org>;
> <linux-scsi@vger.kernel.org>; <linux-kernel@vger.kernel.org>;
> <trivial@rustcorp.com.au>; <torvalds@osdl.org>
> Sent: Saturday, February 25, 2006 7:59 AM
> Subject: Re: [PATCH] sata_promise: Port enumeration order - SATA 150
> TX4, SATA 300 TX4
>
>
>> Milan Kupcevic wrote:
>>
>>> From: Milan Kupcevic <milan@physics.harvard.edu>
>>>
>>> Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4
>>> (PDC40718-GP) wrong port enumeration order that makes it (nearly)
>>> impossible to deal with boot problems using two or more drives.
>>>
>>> Signed-off-by: Milan Kupcevic <milan@physics.harvard.edu>
>>> ---
>>>
>>> The current kernel driver assumes:
>>>
>>> port 1 - scsi3
>>> port 2 - scsi1
>>> port 3 - scsi0
>>> port 4 - scsi2
>>
>>
>> I totally agree with the fact that the Linux driver gets the ports wrong
>> when compared to the BIOS, Windows and surely contradicts the port
>> numbers printed on the board. I doubt we all got samples on the one
>> bad batch...
>>
>> It *is* a real problem and if the solution is correct then I support it.
>>
>> Maybe we need a quick feedback from current users: do you guys find
>> that the ports are detected as they are labelled (white silk screen)
>> on the board or do they show up out of order (as listed above by
>> Milan)?
--
avona media GbR | Neureuter Str. 5-7 | D-76185 Karlsruhe
fon +49 721 53169901 | fax +49 721 53169904 | www.avona.com
^ permalink raw reply
* Re: Oops: mounting floppy disk on PPC64 (power3)
From: Nathan Lynch @ 2006-03-31 22:50 UTC (permalink / raw)
To: Markus Rothe; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <200603312138.16032.markus@unixforces.net>
Hello.
Markus Rothe wrote:
>
> this is kernel 2.6.16.1 compiled with gcc 4.1.0 (gentoo patches). I never
> tried to mount a floppy on this system before, so I don't know if it Oops'ed
> in previous kernel versions, too.
>
> power3 ~ # uname -a
> Linux power3 2.6.16.1 #1 Fri Mar 31 21:08:43 UTC 2006 ppc64 POWER3 (630+) CHRP
> IBM,7044-170 GNU/Linux
> power3 ~ # modprobe floppy
> power3 ~ # mount /mnt/floppy/
> Oops: Kernel access of bad area, sig: 11 [#1]
> NUMA PSERIES
> Modules linked in: floppy
> NIP: C0000000000201E8 LR: D0000000000C43A4 CTR: C0000000000201D8
> REGS: c0000000003df470 TRAP: 0300 Not tainted (2.6.16.1)
> MSR: A000000000001032 <ME,IR,DR> CR: 48000082 XER: 00000000
> DAR: 0000000000000178, DSISR: 0000000040000000
> TASK = c0000000003fc9b0[0] 'swapper' THREAD: c0000000003dc000
> GPR00: C00000000042FC08 C0000000003DF6F0 C0000000004D3310 0000000000000000
> GPR04: C00000000161D000 0000000000000400 0000000000000002 0000000000000750
> GPR08: 0000000000000064 D0000000000D4AE0 D0000000000D5F20 C0000000000201D8
> GPR12: D0000000000CB280 C0000000003FCF80 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 4000000001400000 C0000000003595E0
> GPR20: C0000000003D1F28 00000000017D1A80 C0000000003D1A80 0000000000000060
> GPR24: 00000000000003F0 A000000000009032 0000000000000044 00000000000000D9
> GPR28: 0000000000000400 0000000000000002 D0000000000DB880 C00000000161D000
> NIP [C0000000000201E8] .dma_map_single+0x10/0x70
> LR [D0000000000C43A4] .setup_rw_floppy+0x2c0/0xaa8 [floppy]
> Call Trace:
> [C0000000003DF6F0] [D0000000000C5790] .start_motor+0x108/0x158 [floppy]
> (unreli)
> [C0000000003DF760] [D0000000000C43A4] .setup_rw_floppy+0x2c0/0xaa8 [floppy]
> [C0000000003DF810] [C000000000044714] .run_timer_softirq+0x174/0x20c
> [C0000000003DF8B0] [C00000000003FC68] .__do_softirq+0x80/0x128
> [C0000000003DF940] [C00000000003FD5C] .do_softirq+0x4c/0x68
> [C0000000003DF9C0] [C00000000001C9E8] .timer_interrupt+0x360/0x388
> [C0000000003DFA90] [C0000000000034B8] decrementer_common+0xb8/0x100
> --- Exception: 901 at .ppc64_runlatch_off+0x0/0x50
> LR = .default_idle+0x48/0x70
> [C0000000003DFD80] [C000000000016764] .default_idle+0x68/0x70 (unreliable)
> [C0000000003DFE00] [C0000000000166E8] .cpu_idle+0x40/0x54
> [C0000000003DFE70] [C0000000000092B0] .rest_init+0x3c/0x54
> [C0000000003DFEF0] [C0000000003B16D4] .start_kernel+0x1f0/0x208
> [C0000000003DFF90] [C000000000008514] .start_here_common+0x88/0x174
> Instruction dump:
> 4e800421 e8410028 48000008 0fe00000 38210070 e8010010 7c0803a6 4e800020
> 7c0802a6 f8010010 f821ff91 e80298d0 <e9230178> 7fa90000 409e000c e92298d8
>
> Am I doing something wrong?
Nope.
I believe this was fixed in Linus' tree as of a couple days ago:
diff-tree b239cbe957ae730caa8af2f169a4d35b8c1bb299 (from
69ed3324983bb937d78a857Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue Mar 28 14:40:58 2006 +1100
[PATCH] powerpc: make ISA floppies work again
We used to assume that a DMA mapping request with a NULL dev was
for
ISA DMA. This assumption was broken at some point. Now we
explicitly
pass the detected ISA PCI device in the floppy setup.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Maybe you could verify with latest -git, or 2.6.17-rc1 when it's
released?
^ permalink raw reply
* [DNX#2006040142001258] [U-Boot-Users] [PATCH] Make blackfin configuration [...]
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001258] was created:
<snip>
> Hi Wolfgang,
>
> It's great the Richard's blackfin patch has been applied. But the
> patch it's really old and has some obsolete codes. So I made a patch
> against the current git repository. After applied the patch, the uboot
> can be compiled and work properly on the BF533 STAMP/EZKIT board.
>
> The patch is based on following commit ID in the current U-boot git
> repository.
> ============================================================
> commit ff7fefe6797246b2748530f965f2e41de34a982a
> Author: Wolfgang Denk <wd@pollux.denx.de>
> Date: Mon Mar 13 12:37:35 2006 +0100
>
> Apply SoC concept to arm926ejs CPUs, i.e. move the SoC specific
> timer and
> cpu_reset code from cpu/$(CPU) into the new cpu/$(CPU)/$(SOC)
> directories
> Patch by Andreas Engel, 13 Mar 2006
> ============================================================
> Changelog entry:
> * Make blackfin pass compilation with the current toolchain.
> Patch by Aubrey.Li <aubrey.li@analog.com>
>
> Thanks,
> -Aubrey
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001249] [U-Boot-Users] [PATCH 7/7] Flat device tree suppor [...]
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001249] was created:
<snip>
> * Switched default PCI speed for 8540 ADS back to 33MHz
> * Added comments and a printf to warn that PCI-X won't
> work at 33MHz
>
> ---
>
> cpu/mpc85xx/pci.c | 3 +++
> doc/README.mpc85xxads | 3 +++
> include/configs/MPC8540ADS.h | 6 +++++-
> 3 files changed, 11 insertions(+), 1 deletions(-)
>
> db86eda9e3cd0b3e89bd50965a49b6232f1d97c3
> diff --git a/cpu/mpc85xx/pci.c b/cpu/mpc85xx/pci.c
> index ca11bce..cfb7dcd 100644
> --- a/cpu/mpc85xx/pci.c
> +++ b/cpu/mpc85xx/pci.c
> @@ -72,6 +72,9 @@ pci_mpc85xx_init(struct pci_controller *
>
> if (!(gur->pordevsr & PORDEVSR_PCI)) {
> /* PCI-X init */
> + if (CONFIG_SYS_CLK_FREQ < 66000000)
> + printf("PCI-X will only work at 66 MHz\n");
> +
> reg16 = PCI_X_CMD_MAX_SPLIT | PCI_X_CMD_MAX_READ
> | PCI_X_CMD_ERO | PCI_X_CMD_DPERR_E;
> pci_hose_write_config_word(hose, dev, PCIX_COMMAND, reg16);
> diff --git a/doc/README.mpc85xxads b/doc/README.mpc85xxads
> index f0cf782..ae8202b 100644
> --- a/doc/README.mpc85xxads
> +++ b/doc/README.mpc85xxads
> @@ -100,6 +100,9 @@ Updated 13-July-2004 Jon Loeliger
> SW7[1:4] = 0101 = 5 => 5 x 66 = 330 CCB Sysclk
> SW7[5:6] = 01 => 5:2 x 330 = 825 Core clock
>
> + In order to use PCI-X (only in the first PCI slot. The one with
> + the RIO connector), you need to set SW1[4] (config) to 1 (off).
> + Also, configure the board to run PCI at 66 MHz.
>
> 2. MEMORY MAP TO WORK WITH LINUX KERNEL
>
> diff --git a/include/configs/MPC8540ADS.h b/include/configs/MPC8540ADS.h
> index 81ee945..8e4d2c9 100644
> --- a/include/configs/MPC8540ADS.h
> +++ b/include/configs/MPC8540ADS.h
> @@ -68,10 +68,14 @@
> * The board, however, can run at 66MHz. In any event, this value
> * must match the settings of some switches. Details can be found
> * in the README.mpc85xxads.
> + *
> + * XXX -- Can't we run at 66 MHz, anyway? PCI should drop to
> + * 33MHz to accommodate, based on a PCI pin.
> + * Note that PCI-X won't work at 33MHz.
> */
>
> #ifndef CONFIG_SYS_CLK_FREQ
> -#define CONFIG_SYS_CLK_FREQ 66000000
> +#define CONFIG_SYS_CLK_FREQ 33000000
> #endif
>
>
> --
> 1.2.4
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001231] [U-Boot-Users] [PATCH 03/04] Add Flat Dev Tree con [...]
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001231] was created:
<snip>
> * Add Flat Dev Tree construction for MPC85xx ADS and CDS boards.
> Patch by Jon Loeliger 17-Jan-2006
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
>
> ---
>
> board/cds/common/ft_board.c | 37 +++++++++
> board/cds/mpc8541cds/Makefile | 14 +++-
> board/cds/mpc8541cds/oftree.dts | 137
> +++++++++++++++++++++++++++++++++++
> board/cds/mpc8548cds/Makefile | 14 +++-
> board/cds/mpc8548cds/oftree.dts | 137
> +++++++++++++++++++++++++++++++++++
> board/cds/mpc8555cds/Makefile | 14 +++-
> board/cds/mpc8555cds/oftree.dts | 137
> +++++++++++++++++++++++++++++++++++
> board/mpc8540ads/Makefile | 13 +++
> board/mpc8540ads/mpc8540ads.c | 15 ++++
> board/mpc8540ads/oftree.dts | 137
> +++++++++++++++++++++++++++++++++++
> board/mpc8560ads/Makefile | 12 +++
> board/mpc8560ads/mpc8560ads.c | 9 ++
> board/mpc8560ads/oftree.dts | 153
> +++++++++++++++++++++++++++++++++++++++
> cpu/mpc85xx/cpu.c | 50 ++++++++++++-
> cpu/mpc85xx/cpu_init.c | 1
> include/configs/MPC8540ADS.h | 15 ++++
> include/configs/MPC8541CDS.h | 12 +++
> include/configs/MPC8548CDS.h | 12 +++
> include/configs/MPC8555CDS.h | 12 +++
> include/configs/MPC8560ADS.h | 12 +++
> 20 files changed, 932 insertions(+), 11 deletions(-)
>
>
> diff --git a/board/cds/common/ft_board.c b/board/cds/common/ft_board.c
> new file mode 100644
> index 0000000..8c4ef0c
> --- /dev/null
> +++ b/board/cds/common/ft_board.c
> @@ -0,0 +1,37 @@
> +/*
> + * Copyright 2004 Freescale Semiconductor.
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include <common.h>
> +
> +#if defined(CONFIG_OF_FLAT_TREE)
> +#include <ft_build.h>
> +extern void ft_cpu_setup(void *blob, bd_t *bd);
> +#endif
> +
> +
> +#if defined(CONFIG_OF_FLAT_TREE) && defined(CONFIG_OF_BOARD_SETUP)
> +void
> +ft_board_setup(void *blob, bd_t *bd)
> +{
> + ft_cpu_setup(blob, bd);
> +}
> +#endif
> diff --git a/board/cds/mpc8541cds/Makefile
> b/board/cds/mpc8541cds/Makefile
> index 1161532..34bc410 100644
> --- a/board/cds/mpc8541cds/Makefile
> +++ b/board/cds/mpc8541cds/Makefile
> @@ -28,15 +28,25 @@ LIB = lib$(BOARD).a
>
> OBJS := $(BOARD).o \
> ../common/cadmus.o \
> - ../common/eeprom.o
> + ../common/eeprom.o \
> + ../common/ft_board.o \
> + oftree.o
>
> SOBJS := init.o
>
> $(LIB): $(OBJS) $(SOBJS)
> $(AR) crv $@ $(OBJS)
>
> +%.dtb: %.dts
> + dtc -f -V 0x10 -I dts -O dtb $< >$@
> +
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001221] [U-Boot-Users] [PATCH-2/4] blackfin: rename bf533 [...]
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001221] was created:
<snip>
> ## no text/plain body => see attachment (text/plain) ##
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001212] [U-Boot-Users] [Patch 5/5] Add DataFlash support f [...]
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001212] was created:
<snip>
> DataFlash patch (5/5) adds DataFlash support for ATMEL AT91SAM9261EK
> board.
>
> CHANGELOG
> Patch by Nicolas Lacressonniere 31 January 2006
> * Add DataFlash support for ATMEL AT91SAM9261EK board (arm926ejs)
> * Use CFG_NO_FLASH flag to avoid embedding NOR Flash code and to share
> same
> functions between NOR Flash and DataFlash
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001196] [U-Boot-Users] [PATCH] New support for the Xilinx [...]
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001196] was created:
<snip>
> Attached is a patch and a CHANGELOG entry that adds new support for the
> Xilinx ML403 board.
>
> Please apply to the repository after
> - "Major overhaul for Xilinx ML300 board support" patch
> - CM.patch (same email as above)
> - "New support for the Xilinx ML310 board" patch
> in that order.
>
> Thanks,
> - Peter
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001203] [U-Boot-Users] [PATCH 5/7] Flat device tree suppor [...]
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001203] was created:
<snip>
> * Added PCI and I2C support to 8540 ADS flat device tree
> * Fixed PCI memory definitions
> Patch by Andy Fleming 17-Mar-2006
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
>
> ---
>
> board/mpc8540ads/mpc8540ads.c | 21 ++-------
> board/mpc8540ads/oftree.dts | 98
> +++++++++++++++++++++++++++++++++++++++++
> include/configs/MPC8540ADS.h | 9 ++--
>
> 78e133998e9e91efcd43bf476681aad123c25aaa
> diff --git a/board/mpc8540ads/mpc8540ads.c
> b/board/mpc8540ads/mpc8540ads.c
> index 1252d2a..e7db14b 100644
> --- a/board/mpc8540ads/mpc8540ads.c
> +++ b/board/mpc8540ads/mpc8540ads.c
> @@ -317,24 +317,8 @@ long int fixed_sdram (void)
> * Initialize PCI Devices, report devices found.
> */
>
> -#ifndef CONFIG_PCI_PNP
> -static struct pci_config_table pci_mpc85xxads_config_table[] = {
> - { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> - PCI_IDSEL_NUMBER, PCI_ANY_ID,
> - pci_cfgfunc_config_device, { PCI_ENET0_IOADDR,
> - PCI_ENET0_MEMADDR,
> - PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER
> - } },
> - { }
> -};
> -#endif
> -
>
> -static struct pci_controller hose = {
> -#ifndef CONFIG_PCI_PNP
> - config_table: pci_mpc85xxads_config_table,
> -#endif
> -};
> +static struct pci_controller hose;
>
> #endif /* CONFIG_PCI */
>
> @@ -354,6 +338,9 @@ pci_init_board(void)
> void
> ft_board_setup(void *blob, bd_t *bd)
> {
> +#ifdef CONFIG_PCI
> + ft_pci_setup(blob, bd);
> +#endif
> ft_cpu_setup(blob, bd);
> }
> #endif
> diff --git a/board/mpc8540ads/oftree.dts b/board/mpc8540ads/oftree.dts
> index 290e80e..a505f48 100644
> --- a/board/mpc8540ads/oftree.dts
> +++ b/board/mpc8540ads/oftree.dts
> @@ -54,6 +54,15 @@
> reg = <e0000000 00100000>; // CCSRBAR 1M
> bus-frequency = <0>;
>
> + i2c at 3000 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <3000 100>;
> + interrupts = <1b 0>;
> + interrupt-parent = <40000>;
> + dfsrr;
> + };
> +
> mdio at 24520 {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -120,6 +129,95 @@
> interrupts = <1a 3>;
> interrupt-parent = <40000>;
> };
> + pci at 8000 {
> + linux,phandle = <8000>;
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <
> +
> + /* IDSEL 0x02 */
> + 1000 0 0 1 40000 31 0
> + 1000 0 0 2 40000 32 0
> + 1000 0 0 3 40000 33 0
> + 1000 0 0 4 40000 34 0
> +
> + /* IDSEL 0x03 */
> + 1800 0 0 1 40000 34 0
> + 1800 0 0 2 40000 31 0
> + 1800 0 0 3 40000 32 0
> + 1800 0 0 4 40000 33 0
> +
> + /* IDSEL 0x04 */
> + 2000 0 0 1 40000 33 0
> + 2000 0 0 2 40000 34 0
> + 2000 0 0 3 40000 31 0
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001187] [U-Boot-Users] Xilinx ML403/PPC U-Boot support
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001187] was created:
<snip>
>
> >Careful. ML403 reference design (as-is) is not using the Xilinx option
> >of using side-by-side data access (32-bit fetch out of a single 16-bit
> >flash), so XIP (execution in place) is evidently NOT supported in ML403.
> > However, I had a new bit file built with side-by-side data access
> >enabled, but haven't yet execute out of flash (no need because ML403 has
> >a big memory.) But it correctly fetches 32-bit now. Ping me in a week
> >on my progress with XIP and flash.
> >
> Hmm, why do you need that? The ML403 has two flash chips and with that
> allows 32 bit wide accesses. That allows you to access the whole flash
> space and should give you much better performance than executing out of
> a 16 bit wide flash.
>
> - Peter
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [U-Boot-Users] Re: [DNX#2006040142001178] [PATCH] Enable initrd tag for xm250
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001178] was created:
<snip>
> The attached patch enables the initrd tag for the xm250.
> Signed-off-by: Josef Wagner <wagner <at> microsys.de>
>
>
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001169] [U-Boot-Users] [PATCH] 08-change-boot-delay-messag [...]
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001169] was created:
<snip>
> Change boot delay message on trab board
> Patch by Martin Krause, 27 Oct 2005
>
> In series production versions of trab u-boot, this patch allways
> was applied - but had been forgotten to push it up into denx
> U-Boot tree, since now.
>
> Regards,
> Martin
>
> Signed-off-by: Martin Krause <martin.krause@tqs.de>
>
> CHANGELOG:
> * Change boot delay message on trab board
> Patch by Martin Krause, 27 Oct 2005
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001151] [U-Boot-Users] Xilinx ML403/PPC U-Boot support
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001151] was created:
<snip>
> bbosch at iphase.com wrote:
> > Peter Ryser writes:
> > > BTW: you can find a snapshot of U-Boot with board support for ML300,
> > > ML310, ML403 and ML410 at
> > > http://www.xilinx.com/ml410-p/designs/u-boot.zip
> > > The snapshot contains the patches that have been submitted to this
> > > mailing list back in September of last year. For ML403 just use
> >
> > Wolfgang,
> >
> > Were the Xilinx patches (2005-09-28 thru 2005-10-02) rejected or lost,
> > or are they still in your queue?
> >
>
> I'm also interested whether Xilinx EMAC or TEMAC ethernet driver is
> supported in this...(after reviewing the Xilinx zip file, it doesn't...
> sigh).
>
> However, I do DO have an Ethernet driver for Xilinx EMAC and TEMAC for
> U-boot and it works... Unfortunately, it uses Xilinx copyrighted
> codes... Somehow, I doubt this is what you wanted.
>
> Is Xilinx copyright ok with you?
>
>
> > Peter,
> >
> > Do you happen to have a design for the ML403 that boots directly from
> > the linear flash? Perhaps with devices mapped as in
> > board/xilinx/ml403/xparameters.h? It would be easier to start with a
> > design known to work with U-Boot.
> >
>
> Careful. ML403 reference design (as-is) is not using the Xilinx option
> of using side-by-side data access (32-bit fetch out of a single 16-bit
> flash), so XIP (execution in place) is evidently NOT supported in ML403.
> However, I had a new bit file built with side-by-side data access
> enabled, but haven't yet execute out of flash (no need because ML403 has
> a big memory.) But it correctly fetches 32-bit now. Ping me in a week
> on my progress with XIP and flash.
>
> S. Egbert
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001141] [U-Boot-Users] [Patch 3/5] Add LCD support and ATM [...]
From: DENX Support System @ 2006-03-31 22:50 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001141] was created:
<snip>
> This patch (3/5) adds LCD support and logo for ATMEL AT91SAM9261EK
> board.
>
> atmel.bmp logo should be placed into tools/logos/ directory.
>
> CHANGELOG
> Patch by Nicolas Lacressonniere 31 January 2006
> * Add LCD support and logo for ATMEL AT91SAM9261EK board (arm926ejs)
</snip>
Your U-Boot support team
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.