* Linux on Virtex4
From: Martin, Tim @ 2006-06-19 23:24 UTC (permalink / raw)
To: linuxppc-embedded
I have been working with a small module made by Memec/Avnet
(FX12MM1-BASE) that has a Virtex-4 FX12 with some DDR SDRAM, a Gigabit
Ethernet PHY, some FLASH, etc. I am using EDK 8.1 and generated the BSP
for MontaVista 3.1 "preview kit" (which is based on the 2.4.20 kernel).
This works, but occasionally panics while booting (doesn't panic all the
time, maybe 1/3 the time). Examples of "good" boot and 2 "crash" boots
below. We are using a root filesystem over NFS, and the panics seem to
always be after the file system is mounted. I'm not sure if it is NFS
related or not.
I have also been working with the paulus 2.6 kernel tree (and I have
tried the MVL linux-xilinx-26 tree), but have not been able to get the
kernel to boot. The primary problem there is that we are using the
uartlite instead of the full uart, and the patches I have found for
uartlite support don't work. I can get the early serial messages to
work, but I don't know enough about the console and serial core to get
everything else working. I am also getting panics that seem to be
non-serial related, but I haven't tracked it down yet.
So two questions:
1) Is there anything obvious from the kernel panics below that I should
be looking for? Just the answer "linux 2.4.20 is really fricken old,
upgrade" is probably the right answer.
2) Does anyone have working UartLite support on a Virtex-4 FX12 design?
------------ Examples of 2.4.20 good:
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:mapin_ram done
MMU:setio
MMU:exit
Linux version 2.4.20_mvl31-v4fx12 (ahamel@uhflinux) (gcc version 3.3.1
(MontaVista 3.3.1-3.0.10.6
setup_arch: enter
setup_arch: bootmem
Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc.
(source@mvista.com)
arch: exit
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/nfs
nfsroot=3D192.168.1.1:/opt/montavista/previewkit/ppc/405/target4
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
Calibrating delay loop... 197.01 BogoMIPS
Memory: 63268k available (1092k kernel code, 340k data, 60k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 42
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
xgpio #0 at 0x40020000 mapped to 0xC5000000
xgpio #1 at 0x40040000 mapped to 0xC5011000
xgpio #2 at 0x40060000 mapped to 0xC5022000
xilinx_spi: got major number 254
xilinx_spi0 at 0x40800000 mapped to 0xC5033000, irq=3D29
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
XTemac: Device instance #0 found
eth0: XTemac: using fifo direct interrupt driven mode.
eth0: XTemac: PHY detected at address 4.
eth0: Xilinx TEMAC #0 at 0x80400000 mapped to 0xC5044000, irq=3D28
eth0: XTemac: id 1.0f, block id 5, type 8
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
eth0: XTemac: Options: 0xb8f0
eth0: XTemac: We renegotiated the speed to: 1000
eth0: XTemac: speed set to 1000Mb/s
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.75
IP-Config: Complete:
device=3Deth0, addr=3D192.168.1.75, mask=3D255.255.255.0,
gw=3D192.168.1.1,
host=3D192.168.1.75, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.1.1, rootserver=3D192.168.1.1, rootpath=3D
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.1.1
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 60k init
serial console detected. Disabling virtual terminals.
init started: BusyBox v0.60.2 (2004.04.30-17:49+0000) multi-call binary
Welcome to MontaVista Linux Preview Kit
Starting system...
mounting /proc: done.
Mounting '/' read-only: done.
brining up loopback interface: done.
Mounting /tmp: done.
Starting syslogd: done.
Starting klogd: done.
Starting inetd: done.
Starting thttpd: done.
System started.
MontaVista(R) Linux(R) Professional Edition 3.1, Preview Kit
192.168.1.75 login:
------ Example 1 of panic
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:mapin_ram done
MMU:setio
MMU:exit
Linux version 2.4.20_mvl31-v4fx12 (ahamel@uhflinux) (gcc version 3.3.1
(MontaVista 3.3.1-3.0.10.6
setup_arch: enter
setup_arch: bootmem
Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc.
(source@mvista.com)
arch: exit
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/nfs
nfsroot=3D192.168.1.1:/opt/montavista/previewkit/ppc/405/target4
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
Calibrating delay loop... 197.01 BogoMIPS
Memory: 63268k available (1092k kernel code, 340k data, 60k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 42
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
xgpio #0 at 0x40020000 mapped to 0xC5000000
xgpio #1 at 0x40040000 mapped to 0xC5011000
xgpio #2 at 0x40060000 mapped to 0xC5022000
xilinx_spi: got major number 254
xilinx_spi0 at 0x40800000 mapped to 0xC5033000, irq=3D29
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
XTemac: Device instance #0 found
eth0: XTemac: using fifo direct interrupt driven mode.
eth0: XTemac: PHY detected at address 4.
eth0: Xilinx TEMAC #0 at 0x80400000 mapped to 0xC5044000, irq=3D28
eth0: XTemac: id 1.0f, block id 5, type 8
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
eth0: XTemac: Options: 0xb8f0
eth0: XTemac: We renegotiated the speed to: 1000
eth0: XTemac: speed set to 1000Mb/s
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.75
IP-Config: Complete:
device=3Deth0, addr=3D192.168.1.75, mask=3D255.255.255.0,
gw=3D192.168.1.1,
host=3D192.168.1.75, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.1.1, rootserver=3D192.168.1.1, rootpath=3D
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.1.1
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 60k init
nfs: server 192.168.1.1 not responding, still trying
Oops: kernel access of bad area, sig: 11
NIP: C00F05B4 XER: 20000000 LR: C00F0C80 SP: C0131C80 REGS: c0131bd0
TRAP: 0800 Not tainted
MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DEAR: 00000045, ESR: 00000000
TASK =3D c0130020[0] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: C00CA728 C0131C80 C0130020 00000001 00001030 00000000 C02C9180
C023F9F8
GPR08: C02CA000 C0150000 00000003 00001DC7 84002022 1006E950 03FD0000
00000000
GPR16: 00000001 00000001 FFFFFFFF 007FFF00 00001032 00131EE0 00000000
C0000000
GPR24: C0151D24 C02C90D0 C0150000 00000000 C0157F00 C02E8080 C02C90D8
C02E8080
Call backtrace:
C00F0A4C C00CA728 C00EED30 C00C2958 C00200DC C001BD20 C001BB9C
C001B868 C0005E48 C00047CC C00274E4 C0005D80 C0005D94 C0002434
C01425CC C000232C
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
<0>Rebooting in 180 seconds..
------- Example 2 of crash
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:mapin_ram done
MMU:setio
MMU:exit
Linux version 2.4.20_mvl31-v4fx12 (ahamel@uhflinux) (gcc version 3.3.1
(MontaVista 3.3.1-3.0.10.6
setup_arch: enter
setup_arch: bootmem
Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc.
(source@mvista.com)
arch: exit
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/nfs
nfsroot=3D192.168.1.1:/opt/montavista/previewkit/ppc/405/target4
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
Calibrating delay loop... 197.01 BogoMIPS
Memory: 63268k available (1092k kernel code, 340k data, 60k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 42
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
xgpio #0 at 0x40020000 mapped to 0xC5000000
xgpio #1 at 0x40040000 mapped to 0xC5011000
xgpio #2 at 0x40060000 mapped to 0xC5022000
xilinx_spi: got major number 254
xilinx_spi0 at 0x40800000 mapped to 0xC5033000, irq=3D29
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
XTemac: Device instance #0 found
eth0: XTemac: using fifo direct interrupt driven mode.
eth0: XTemac: PHY detected at address 4.
eth0: Xilinx TEMAC #0 at 0x80400000 mapped to 0xC5044000, irq=3D28
eth0: XTemac: id 1.0f, block id 5, type 8
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
eth0: XTemac: Options: 0xb8f0
eth0: XTemac: We renegotiated the speed to: 1000
eth0: XTemac: speed set to 1000Mb/s
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.75
IP-Config: Complete:
device=3Deth0, addr=3D192.168.1.75, mask=3D255.255.255.0,
gw=3D192.168.1.1,
host=3D192.168.1.75, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.1.1, rootserver=3D192.168.1.1, rootpath=3D
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.1.1
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 60k init
serial console detected. Disabling virtual terminals.
init started: BusyBox v0.60.2 (2004.04.30-17:49+0000) multi-call binary
Welcome to MontaVista Linux Preview Kit
Starting system...
mounting /proc: done.
Mounting '/' read-only: done.
brining up loopback interface: done.
Mounting /tmp: done.
Starting syslogd: done.
Starting klogd: done.
Starting inetd: done.
Starting thttpd: done.
System started.
Oops: Exception in kernel mode, sig: 4
NIP: C010D660 XER: 00000000 LR: C010D6F0 SP: C3EB7E60 REGS: c3eb7db0
TRAP: 0700 Not tainted
MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK =3D c3eb6000[48] 'insmod' Last syscall: 90
last math 00000000 last altivec 00000000
GPR00: 00000001 C3EB7E60 C3EB6000 C3F06CD8 C014F524 C014DAE0 C014DB00
C014DAF8
GPR08: C014D000 C3F06C78 0000001C C014D9D8 24022222 00000000 300277F8
00000000
GPR16: 10001AA1 7FFFF118 00000030 C0150000 00000000 FFFFFFF4 00000002
00000002
GPR24: 00100077 00000032 00000000 00000001 C014F524 C014DAF8 C3F06CD8
C014D9D8
Call backtrace:
C002A84C C0029684 C0029BC0 C0009DE0 C000459C 3000646C 30007784
3000B810 3000CE68 3000C1F8 30002FE8 3000F7F0 30001FDC 30002434
30010904
kernel BUG at mmap.c:1304!
Oops: Exception in kernel mode, sig: 4
NIP: C002AD48 XER: 00000000 LR: C002AD48 SP: C3EB7C60 REGS: c3eb7bb0
TRAP: 0700 Not tainted
MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK =3D c3eb6000[48] 'insmod' Last syscall: 90
last math 00000000 last altivec 00000000
GPR00: C002AD48 C3EB7C60 C3EB6000 0000001B 00001030 00000001 00000F14
C0139D93
GPR08: 00000000 00000000 00000034 C3EB7B70 C0150000 00000000 300277F8
00000000
GPR16: 10001AA1 7FFFF118 00000030 C0150000 00009032 03EB7DA0 00000000
C00047D4
GPR24: C0004BC4 C0150000 C0150000 00000000 00001000 7FFFF000 C014F520
00000000
Call backtrace:
C002AD48 C0014684 C0019EE8 C000497C C00049EC C00047D4 C002A84C
C0029684 C0029BC0 C0009DE0 C000459C
^ permalink raw reply
* Re: [PATCH 5/9 v3] Add the MPC8641 HPCN platform files.
From: Segher Boessenkool @ 2006-06-19 23:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FsSuB-0000Qc-P6@jdl.com>
>> In that case you obviously need to sync the timebases, sure.
>> The firmware could be smart and do the sync at CPU start-up
>> time though.
>
> I am investigating this and, as I indicated to Ben, submit
> a follow up patch to implement it if I figure out to do it.
Great.
>> In
>> some cases the kernel explicitly tells the firmware to start/
>> stop the timebases, that's better than the kernel having to
>> handle the nitty-gritty details itself already.
>>
>> Thoughts?
>
> Well, by the time Linux is running, there is no more firmware
> available. Linux is essentially autononomous at this stage,
> and I think it will have to arrange for the TB sync itself.
I'm confused now. So are or arent't all CPUs running at the
time Linux is started? Are you saying Linux manually starts
all non-boot CPUs?!?
Segher
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Benjamin Herrenschmidt @ 2006-06-19 23:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Becky Bruce, linuxppc-dev list
In-Reply-To: <3E324A7E-388E-4917-B380-B0831A5F9D19@kernel.crashing.org>
> If there's any interrupt in the dev tree, there should be an interrupt
> controller. If the requirement is more strict than that, that's a
> bug :-)
Yes, I should make that clearer.
> Most "real" device trees (on a "real" OF) do not have "interrupt-
> controller"
> as the name of their main interrupt controller nodes. This sounds
> like a
> spec bug.
I haven't specified that it _should_ be called interrupt-controller, but
it's generally called that way at least on chrp/pSeries and I think
there's an OF recommended practices RFC that says something around those
lines, so I changed the examples to reflect that.
> > "In general, the format of an address for a device is defined by the
> > parent bus type, based on the #address-cells and #size-cells
> > property. In the absence of such a property, the parent's parent
> > values are used, etc..."
>
> Bad already; #size-cells has nothing to do with addresses (it's
> important for address _ranges_ though).
That's an old bit of the spec that you could have commented on a long
time ago :) Though a "reg" property contains an address range and the
above was talking about those mostly. I need to clarify. In addition,
the default-to-parent thing is something I'll remove from the spec and
write that the absence of the property is undefined I think. We'll keep
the current behaviour in linux for now though.
> > The additions in the patch specify new requirements that don't seem
> > to match up with the statement above. In the new patch, #address-
> > cells is listed as a required node for interrupt-controller nodes,
> > there's no mention of inheritance from a parent,
>
> Inheritance from the parent does not exist, in real OF. Absence of
> #address-cells means "default to 2". This needs to be fixed in DTC.
Yes. Except that I will probably not do the "default to 2". The kernel
doesn't do it and there might still be things relying on the old
(broken) linux behaviour. Thus I'll probably spec it as undefined.
> > and in one place in
> > the Nexus section, it's stated that if there's no #address-cells node
> > the kernel assumes it's 0.
>
> Also wrong. Although I think that's what the IMAP thing says as well...
Yes, it seems the default is different when parsing interrupts... at
least when hitting an interrupt-controller node, which is not a standard
address parsing.
> > I think the doc needs a bit of clarification in this area.
>
> Yeah.
>
> Just *require* #address-cells for everything with addressable sub-nodes,
> at least in DTC. Doesn't cost much, and no confusion anymore.
Yes. We should do that.
In the case of interrupt controllers/nexus, #address-cells is not for
addressable sub-nodes though but for defining the format of unit
interrupt specifiers for interrupt-childs which aren't necessary sub
nodes... confusing heh ?
Ben
^ permalink raw reply
* Re: kernel-x64-smp-multiprocessor-time util problem
From: Bernd Petrovitsch @ 2006-06-19 23:17 UTC (permalink / raw)
To: art; +Cc: linux-kernel
In-Reply-To: <20060619180413.qlgd1oj9etmosckg@69.222.0.225>
On Mon, 2006-06-19 at 18:04 -0500, art@usfltd.com wrote:
> on dual core amd-athlon under 64bit-smp core
>
> kernel compilation time:
>
> time make -j 8
> ...
> LD [M] sound/usb/snd-usb-lib.ko
> LD [M] sound/usb/usx2y/snd-usb-usx2y.ko
>
> real 18m0.948s
> user 26m6.270s ------bad
> sys 4m22.256s ------?bad
> [xxx@localhost linux-2.6.17]$
> --- real-clock time is ~18 min -- user and system time doubled?
How many virtual CPUs (i.e. HT is "2 CPUs") do you have in that machine?
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: intelfb updates
From: Dave Airlie @ 2006-06-19 23:14 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: Eric Hustvedt, Antonino A. Daplas
In-Reply-To: <52176753-4100-4290-963B-C9D1B73526D0@cecropia.com>
> dave --
>
> just wanted to follow up on this. You latest commit in your git tree
> fixed the problem for me. I now have a working display with just
> your patchset :)
I thought it might, I'm going to put my latest tree into 2.6.18, and
I'll add your i2c stuff to my -mm tree for now... It might get into
2.6.18 later..
Dave.
>
> dennis
>
> On Jun 7, 2006, at 4:55 AM, Dave Airlie wrote:
>
> > Wow, can you give me some numbers from the old/new calc_vclock?
> >
> > what does it return when it works and when it doesn't work?
> >
> > I'm unsure what could be different on i945, but I'm sure something
> > could be :-)
> >
> > Dave.
>
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Jon Loeliger @ 2006-06-19 23:14 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Becky Bruce, linuxppc-dev list
In-Reply-To: <72C71D61-F43A-4644-BBE8-F8B3B8526195@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
> >> Just *require* #address-cells for everything with addressable sub-
> >> nodes,
> >> at least in DTC. Doesn't cost much, and no confusion anymore.
> >
> > Woot! Send me a patch! :-)
>
> Noooo... tiiiime... And way too lazy.
Jinx.
> Could you pick this up, please?
I would not be able to get anywhere near it until
significantly into August at the very earliest.
Really.
jdl
^ permalink raw reply
* Re: [PATCH] entry_data
From: Patrick McHardy @ 2006-06-19 23:13 UTC (permalink / raw)
To: Massimiliano Hofer; +Cc: netfilter-devel
In-Reply-To: <200606200035.07197.max@nucleus.it>
Massimiliano Hofer wrote:
> On Monday 19 June 2006 7:34 pm, Patrick McHardy wrote:
>
>
>>Yes, userspace ignores these fields. I still haven't really made up my
>>mind about this patch yet. I don't like the void ** approach very much,
>
>
> I understand your concerns, but it's either that or feeding it its own struct
> xt_entry_match *. This would be awfully circular, while the practice of
> passing someting * to functions is widespread. This only happens to be
> applied to a void *.
I guess I just like externally allocated storage better (and a .privsize
field or something in the match structures). It avoids each match having
to deal with memory allocation failures and more complicated cleanup
code. Currently some matches store state in the structures shared with
userspace and keep a pointer to the first per-CPU copy so there is only
a single state on SMP, others allocate memory and keep a pointer in the
shared struct, yet others keep global state and do lookups based on some
identifier in the shared struct. The first two cases really just want
some amount of memory that is shared between per-CPU data and are happy
with externally allocated memory, the last one is usually used to share
state between selected instances of matches or targets, which will
always need to be handled internally.
So I think we should introduce a .priv_size field or something in struct
xt_match/xt_target and pass memory allocated by xtables to the matches
and targets.
^ permalink raw reply
* kernel-x64-smp-multiprocessor-time util problem
From: art @ 2006-06-19 23:04 UTC (permalink / raw)
To: linux-kernel
on dual core amd-athlon under 64bit-smp core
kernel compilation time:
time make -j 8
...
LD [M] sound/usb/snd-usb-lib.ko
LD [M] sound/usb/usx2y/snd-usb-usx2y.ko
real 18m0.948s
user 26m6.270s ------bad
sys 4m22.256s ------?bad
[xxx@localhost linux-2.6.17]$
--- real-clock time is ~18 min -- user and system time doubled?
art@usfltd.com
^ permalink raw reply
* Re: 2.6.16.x CPUFREQ / SpeedStep-Centrino: couldn't enable Enchanced SpeedStep
From: Dave Jones @ 2006-06-19 23:13 UTC (permalink / raw)
To: Ben Kevan; +Cc: cpufreq, linux
In-Reply-To: <200606191610.40597.ben.kevan@gmail.com>
On Mon, Jun 19, 2006 at 04:10:40PM -0700, Ben Kevan wrote:
> Hi,
>
> I copied both on this because I thought you both may be interested. My problem
> is, my Toshiba Tecra M1 will only run at 598Mhz, and I can not use toshutils
> or anything else to configure speedstep to run higher. Or in any other way
> can I use it to run higher.
>
> Below are a bunch of commands to give you an idea of what's going on. Is this
> a bug with the 2.6.16.x build? Or is it something else that I am just
> oblivious too (ACPI?).
>
> Any information would be greatly appreciated.
>
> LSHESU01004839:/home/bkevan # dmesg | grep speedstep
> speedstep-centrino: couldn't enable Enhanced SpeedStep
> speedstep-centrino: couldn't enable Enhanced SpeedStep
> speedstep-centrino: couldn't enable Enhanced SpeedStep
> speedstep-centrino: couldn't enable Enhanced SpeedStep
>
> LSHESU01004839:/home/bkevan # modprobe speedstep_centrino
> FATAL: Error inserting speedstep_centrino
> (/lib/modules/2.6.16.13-4-default/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko):
> No such device
> LSHESU01004839:/home/bkevan # modprobe acpi_cpufreq
> FATAL: Error inserting acpi_cpufreq
> (/lib/modules/2.6.16.13-4-default/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko):
> No such device
>
Does this still happen in 2.6.17 ?
If so, can you boot with cpufreq.debug=7 and post the output of dmesg here ?
Thanks,
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Benjamin Herrenschmidt @ 2006-06-19 23:12 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list
In-Reply-To: <EC61A880-9242-4BCE-B72D-8AFC038CD592@freescale.com>
> One concern is this stated requirement that a tree have an interrupt-
> controller node. It's not uncommon (in fact, I'm doing it right
> now...) for FSL and some of our customers to build and run the kernel
> on a simulator that has only a processor core, memory, and a memory-
> mapped pseudo-terminal. The terminal does not generate interrupts,
> but is polled from the Decrementer interrupt. So I do not have an
> interrupt controller in the "system" at all.
You don't need an interrupt controller if you don't take interrupts ;)
> How are you planning to enforce this requirement? I believe the dtc
> I have right now warns me about no interrupt-controller node, but it
> builds the tree anyway, and I can boot my kernel just fine. If all
> I'll need to do to get this working in the new world order is to add
> an "interrupt-controller" property to my soc node, I can deal with
> that. I just don't want the kernel to konk out and refuse to boot if
> it doesn't find any interrupts.
If you don't have interrupts, there is no problem. If you do, well, in
fact, I wrote my remapping core in such a way that it _can_ work without
interrupt controller nodes. There are ways to hack around... But you
won't be able to use the OF-parsing facilities to obtain interrupt
mapping of course.
I suppose I should update the above to say "If your platform can handle
external interrupts..."
> > 3) Representing devices without a current OF specification
> > @@ -1263,11 +1305,12 @@
> >
> > Example :
> >
> > - pic@40000 {
> > + interrupt-controller@40000 {
> > linux,phandle = <40000>;
> > clock-frequency = <0>;
> > interrupt-controller;
> > #address-cells = <0>;
> > + #interrupt-cells = <2>;
> > reg = <40000 40000>;
> > built-in;
> > compatible = "chrp,open-pic";
> > @@ -1445,6 +1488,314 @@
> I'm curious about why you chose to rename the pic node here - now we
> have interrupt-controller as a device name, as well as an interrupt-
> controller property inside the device. Reading the rest of this doc,
> the latter should be sufficient. Is this just a stylistic decision?
It's a common practice to name it that way, like it's a common practice
to name ethernet controllers "ethernet"... doesn't _have_ to be that
way. There is an OF RFC or something, I cna't remember the details, that
defines that kind of standard naming.
> >
> > +1) Interrupt controllers
> > +------------------------
> > +
> > +An interrupt controller is identified by the presence of an empty
> > +"interrupt-controller" property in the node. It must also have those
> > +two required properties:
> > +
> > + - linux,phandle : The normally optional phandle is required
> > for an
> > + interrupt controller node as that node will have to be
> > + referrenced by phandle by other nodes (childs and nexus).
> > + - #interrupt-cells : This property contains one cell indicating
> > + the size of the child interrupt specifiers (number of
> > + cells). For example, both ISA and OpenPIC standard specifiers
> > + are 2 cells long (interrupt source number and trigger type)
> > thus
> > + the interrupt-controller node for these shall contain a
> > + #interrupt-cells property with the value <2>.
> > +
> > +In addition, it needs that optional property if there is ever a nexus
> > +pointing to that controller:
> > +
> > + - #address-cells : This is generally the value 0 for an interrupt
> > + controller, the reason why this property is needed is described
> > + in the documentation of an interrupt nexus.
> > +
>
> I think there is some potential for confusion to the reader about the
> required use of #address-cells. In the original document, we talk
> about how devices without an #address-cells property derive the value
> from the parent:
Which is incorrect according to the spec. It's a "feature" we had in the
kernel to work around a ouple of broken device-trees in early Apple OFs
iirc, and when drafting that initial spec, I incorrectly assumed it was
standard OF.
> "In general, the format of an address for a device is defined by the
> parent bus type, based on the #address-cells and #size-cells
> property. In the absence of such a property, the parent's parent
> values are used, etc..."
Yes, and that's wrong. In the case of an interrupt nexus, I would like
to enforce it anyway for various reasons, like the fact that it
simplifies the parsing when hop'ing through more than one interrupt
parent to require explicit #address-cells on interrupt controllers and
interrupt nexus.
> The additions in the patch specify new requirements that don't seem
> to match up with the statement above. In the new patch, #address-
> cells is listed as a required node for interrupt-controller nodes,
> there's no mention of inheritance from a parent, and in one place in
> the Nexus section, it's stated that if there's no #address-cells node
> the kernel assumes it's 0.
>
> I think the doc needs a bit of clarification in this area.
Yup. #address-cells is mandatory to be able to parse the "parent" unit
interrupt specifier part of an interrupt-map. Thus the interrupt
controller must provide one. Since in most case, the parent unit
interrupt specifiers don't contain a unit address, but just an interrupt
line and sense, thus interrupt-controllers shall expose that by having a
#address-cells with a value of 0.
Now regarding default values, it's unclear. The OF interrupt mapping
document seems to imply that when parsing the interrupt tree, the
absence of a #address-cells in the interrupt parent means no unit
address while the OF spec defines a default value of 2 for a missing
#address-cells when parsing device addresse...
> I think it would be useful to continue the example here, and show an
> "interrupt-map" property definition with all the fields filled in.
That's the goal :) I didn't have time to write examples yet.
> Perhaps you were planning to do this as part of your PCI examples; if
> so just ignore this.
Yes. PCI is the typical case of using interrupt-map's
Ben.
^ permalink raw reply
* Re: [PATCH 5/9 v3] Add the MPC8641 HPCN platform files.
From: Jon Loeliger @ 2006-06-19 23:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <A609CF22-66E8-404C-A6F2-528BE097BF57@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
>
> In that case you obviously need to sync the timebases, sure.
> The firmware could be smart and do the sync at CPU start-up
> time though.
I am investigating this and, as I indicated to Ben, submit
a follow up patch to implement it if I figure out to do it.
> In
> some cases the kernel explicitly tells the firmware to start/
> stop the timebases, that's better than the kernel having to
> handle the nitty-gritty details itself already.
>
> Thoughts?
Well, by the time Linux is running, there is no more firmware
available. Linux is essentially autononomous at this stage,
and I think it will have to arrange for the TB sync itself.
jdl
^ permalink raw reply
* 2.6.16.x CPUFREQ / SpeedStep-Centrino: couldn't enable Enchanced SpeedStep
From: Ben Kevan @ 2006-06-19 23:10 UTC (permalink / raw)
To: linux; +Cc: cpufreq
Hi,
I copied both on this because I thought you both may be interested. My problem
is, my Toshiba Tecra M1 will only run at 598Mhz, and I can not use toshutils
or anything else to configure speedstep to run higher. Or in any other way
can I use it to run higher.
Below are a bunch of commands to give you an idea of what's going on. Is this
a bug with the 2.6.16.x build? Or is it something else that I am just
oblivious too (ACPI?).
Any information would be greatly appreciated.
LSHESU01004839:/home/bkevan # dmesg | grep speedstep
speedstep-centrino: couldn't enable Enhanced SpeedStep
speedstep-centrino: couldn't enable Enhanced SpeedStep
speedstep-centrino: couldn't enable Enhanced SpeedStep
speedstep-centrino: couldn't enable Enhanced SpeedStep
LSHESU01004839:/home/bkevan # modprobe speedstep_centrino
FATAL: Error inserting speedstep_centrino
(/lib/modules/2.6.16.13-4-default/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko):
No such device
LSHESU01004839:/home/bkevan # modprobe acpi_cpufreq
FATAL: Error inserting acpi_cpufreq
(/lib/modules/2.6.16.13-4-default/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko):
No such device
LSHESU01004839:/home/bkevan # cpufreq-info
cpufrequtils 0.4: cpufreq-info (C) Dominik Brodowski 2004
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
LSHESU01004839:/home/bkevan # uname -r
2.6.16.13-4-default
LSHESU01004839:/home/bkevan # cat /proc/acpi/processor/C*/info
processor id: 0
acpi id: 1
bus mastering control: yes
power management: yes
throttling control: no
limit interface: no
LSHESU01004839:/home/bkevan # cat /proc/acpi/processor/C*/limit
<not supported>
LSHESU01004839:/home/bkevan # cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 9
model name : Intel(R) Pentium(R) M processor 1600MHz
stepping : 5
cpu MHz : 598.582
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat
clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
bogomips : 1198.30
^ permalink raw reply
* Re: [ckrm-tech] [PATCH 0/4] sched: Add CPU rate caps
From: Peter Williams @ 2006-06-19 23:09 UTC (permalink / raw)
To: balbir
Cc: Peter Williams, Andrew Morton, dev, vatsa, ckrm-tech, bsingharora,
efault, linux-kernel, kernel, sam, kingsley, mingo, rene.herman
In-Reply-To: <44968B6D.8040301@in.ibm.com>
Balbir Singh wrote:
> Peter Williams wrote:
>
>>
>> You're over engineering and you're not solving the problem. You're
>> just moving it down a bit.
>>
>
>>
>>>
>>> 2. In a group based cap management system, schedule some tasks
>>> (highest priority)
>>> until their cap run out. In the subsequent rounds pick and choose
>>> tasks that
>>> did not get a chance to run earlier.
>>>
>>> Solving this is indeed a interesting problem.
>>>
>>
>>
>> Once again, you're over engineering and probably making the problem
>> worse.
>>
>
> I like this term over-engineering. Lets focus on the solution for the most
> common case and see what works out. I was pointing you to the possible
> limitations of the approach, which is always a good thing to do in
> engineering.
And I was pointing out that it's a fundamental limitation that can't be
avoided no matter which implementation route you follow.
Peter
--
Dr Peter Williams, Chief Scientist <peterw@aurema.com>
Aurema Pty Limited
Level 2, 130 Elizabeth St, Sydney, NSW 2000, Australia
Tel:+61 2 9698 2322 Fax:+61 2 9699 9174 http://www.aurema.com
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Segher Boessenkool @ 2006-06-19 23:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Becky Bruce, linuxppc-dev list
In-Reply-To: <E1FsSmY-0000Oz-P2@jdl.com>
>> Just *require* #address-cells for everything with addressable sub-
>> nodes,
>> at least in DTC. Doesn't cost much, and no confusion anymore.
>
> Woot! Send me a patch! :-)
Noooo... tiiiime... And way too lazy.
Could you pick this up, please?
Segher
^ permalink raw reply
* Re: Group write not working in 2.6.16.X
From: Neil Brown @ 2006-06-19 23:06 UTC (permalink / raw)
To: Dan Ohnesorg; +Cc: nfs
In-Reply-To: <20060605155427.GQ27961@ohnesorg.cz>
On Monday June 5, Dan@ohnesorg.cz wrote:
>
> I have found strange problem with nfs after upgrading from kernel 2.6.14 to
> 2.6.16.
>
> System on both ends is Debian Sarge with all patches. We use user space nfs
> server.
>
> Problem is, that a file with group write permission is not writable by this
> group, lets have a server called server and client called client, on server
> export directory /data/export
>
> server# cat /etc/exports
> /data/export 192.168.0.2/255.255.255.255(rw,no_root_squash,sync)
>
> and mount them on client
>
> client# mount -t nfs server:/data/export /mnt/data
>
> than try on client
>
> client# cd /mnt/data
> client# echo "Hi" > file.txt
> client# chmod g+w file.txt
> client# su - someuser
> client$ cd /mnt/data
> client$ echo "Hi2" >> file.txt
> -su: test: Permission denied
Could you please re-run the experiment with calls to 'groups' and
'ls -l file.text' and suitable points so that we can see that
someuser really does have group write.
Can you collect a tcpdump trace while this is happening.
e.g.
tcpdump -w /tmp/trace -s 1500 host SERVER and host CLIENT and port 2049
and compress/attach /tmp/trace.
Thanks,
NeilBrown
>
> this problem occures only with kernel 2.6.16 on client side, after reboot to
> 2.6.14 the append works great with same configuration. Another important hit
> is, that the problem is only in directory, where the nfs tree is mounted, on
> subdirectories is everythink working properly.
>
> Is this bug or are oldes kernels buggy and now is the situation corrected?
>
> cheers
> dan
>
>
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: sata_mv driver on 88sx6041 (kernel version 2.6.13)
From: Narendra Hadke @ 2006-06-19 23:06 UTC (permalink / raw)
To: Mark Lord; +Cc: linux-kernel
In-Reply-To: <4496B47B.7070602@rtr.ca>
Thanks.
I moved further with the 2.6.20 sata_mv driver. Here
are the excerpts from dmesg with ata3 error messages
as follows:
sata_mv 0000:00:0d.0: version
PCI: Enabling device 0000:00:0d.0 (0000 -> 0003)
sata_mv 0000:00:0d.0: 32 slots 4 ports SCSI mode IRQ
via INTx
ata1: SATA max UDMA/133 cmd 0x0 ctl 0x80011B0008022120
bmdma 0x0 irq 45
ata2: SATA max UDMA/133 cmd 0x0 ctl 0x80011B0008024120
bmdma 0x0 irq 45
ata3: SATA max UDMA/133 cmd 0x0 ctl 0x80011B0008026120
bmdma 0x0 irq 45
ata4: SATA max UDMA/133 cmd 0x0 ctl 0x80011B0008028120
bmdma 0x0 irq 45
ata1: no device found (phy stat 00000000)
scsi0 : sata_mv
ata2: no device found (phy stat 00000000)
scsi1 : sata_mv
ata3: dev 0 ATA-6, max UDMA/133, 156301488 sectors:
LBA48
ata3: qc timeout (cmd 0xef)
ata3: failed to set xfermode, disabled
ata3: dev 0 configured for UDMA/133
scsi2 : sata_mv
ata4: no device found (phy stat 00000000)
scsi3 : sata_mv
physmap flash device: 800000 at 1f400000
What is the significance of the
ata3: qc timeout (cmd 0xef)
ata3: failed to set xfermode, disabled
I am not able to get to the drive as attach is not
happening yet.
Thanks for the help.
Narendra
--- Mark Lord <lkml@rtr.ca> wrote:
> Narendra Hadke wrote:
> > Hi,
> > I am using sata_mv driver as exists in kernel
> 2.6.13,
> > reached to a stage where after detecting the disk,
> > control gets struck. Any ideas?
>
> No surprises there. The sata_mv driver is horribly
> buggy
> in all kernels prior to 2.6.16, and even there it
> still has
> some serious bugs. The 2.6.17 kernel version is
> MUCH better.
>
> Cheers
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH, RFT] bcm43xx: Busting the 1G limit
From: Daniel Gryniewicz @ 2006-06-19 23:06 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, netdev
In-Reply-To: <200606192243.09039.mb@bu3sch.de>
On Mon, 2006-06-19 at 22:43 +0200, Michael Buesch wrote:
> On Monday 19 June 2006 17:23, Daniel Gryniewicz wrote:
> > On Sat, 2006-06-17 at 19:28 +0200, Michael Buesch wrote:
> > > Hi,
> > >
> > > This patch adds full 32-bit and 64-bit DMA support
> > > to the bcm43xx driver. Well, it _should_ do this. I can
> > > not test it, as I don't have a machine to trigger the 1G
> > > limit.
> > > The 1G limit should be exploitable on an AMD64 machine
> > > with more than 1G RAM.
> > >
> > > Please test and report, if it works or not. In the
> > > case of "works not", please provide full dmesg log.
> > >
> > > Note that I am not sure which cards actually support
> > > full 32-bit or even 64-bit mode. Older cards might still
> > > only support 30-bit DMA.
> >
> > Hi.
> >
> > I tried this on both 2.6.17-rc6 and on wireless-dev, and got pretty much
> > the same panic on both (modulo locking). My box is a turion with 2 GB
> > of ram and a BCM4318. Here's the panic from wireless-dev:
> >
> > Unable to handle kernel NULL pointer dereference at 0000000000000020
> > RIP:
> > <ffffffff88104f24>{:bcm43xx:bcm43xx_dma_handle_xmitstatus+436}
>
> I am still not absolutely sure where this oops comes from.
> Could you remove at least 1G of your RAM and retry?
>
I took out 1G of RAM (2 1G sticks), and there was no more panic. It
still didn't work (no output from iwlist scan), but also no panic.
dmesg output was:
Jun 19 18:00:54 athena bcm43xx: Radio turned on
Jun 19 18:00:54 athena bcm43xx: ASSERTION FAILED (radio_attenuation <
10) at:
drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1485:bcm43xx_find_lopair()
Jun 19 18:00:54 athena bcm43xx: ASSERTION FAILED (radio_attenuation <
10) at:
drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1485:bcm43xx_find_lopair()
Jun 19 18:00:54 athena bcm43xx: Chip initialized
Jun 19 18:00:54 athena bcm43xx: 32-bit DMA initialized
Jun 19 18:00:54 athena bcm43xx: 80211 cores initialized
Jun 19 18:00:54 athena bcm43xx: Keys cleared
Jun 19 18:00:54 athena SoftMAC: Associate: Scanning for networks first.
Jun 19 18:00:54 athena SoftMAC: Associate: failed to initiate scan. Is
device up?
followed by a bunch of:
Jun 19 18:01:15 athena SoftMAC: Start scanning with channel: 1
Jun 19 18:01:15 athena SoftMAC: Scanning 14 channels
Jun 19 18:01:15 athena SoftMAC: Scanning finished
followed by:
Jun 19 18:02:03 athena SoftMAC: Associate: Scanning for networks first.
Jun 19 18:02:03 athena SoftMAC: Start scanning with channel: 1
Jun 19 18:02:03 athena SoftMAC: Scanning 14 channels
Jun 19 18:02:03 athena bcm43xx: set security called
Jun 19 18:02:03 athena bcm43xx: .level = 0
Jun 19 18:02:03 athena bcm43xx: .enabled = 0
Jun 19 18:02:03 athena bcm43xx: .encrypt = 0
Jun 19 18:02:03 athena SoftMAC: Scanning finished
Jun 19 18:02:03 athena SoftMAC: Associate: Scanning for networks first.
Jun 19 18:02:03 athena SoftMAC: Start scanning with channel: 1
Jun 19 18:02:03 athena SoftMAC: Scanning 14 channels
Jun 19 18:02:03 athena SoftMAC: Scanning finished
Jun 19 18:02:03 athena SoftMAC: Associate: Scanning for networks first.
Jun 19 18:02:03 athena SoftMAC: Start scanning with channel: 1
Jun 19 18:02:03 athena SoftMAC: Scanning 14 channels
Jun 19 18:02:04 athena SoftMAC: Scanning finished
Jun 19 18:02:04 athena SoftMAC: Unable to find matching network after
scan!
and finally:
Jun 19 18:02:44 athena bcm43xx: Radio turned off
Jun 19 18:02:44 athena bcm43xx: DMA-32 0x0200 (RX) max used slots: 0/64
Jun 19 18:02:44 athena bcm43xx: DMA-32 0x02A0 (TX) max used slots: 0/512
Jun 19 18:02:44 athena bcm43xx: DMA-32 0x0280 (TX) max used slots: 0/512
Jun 19 18:02:44 athena bcm43xx: DMA-32 0x0260 (TX) max used slots: 0/512
Jun 19 18:02:44 athena bcm43xx: DMA-32 0x0240 (TX) max used slots: 0/512
Jun 19 18:02:44 athena bcm43xx: DMA-32 0x0220 (TX) max used slots: 2/512
Jun 19 18:02:44 athena bcm43xx: DMA-32 0x0200 (TX) max used slots: 0/512
At that point, I remove the bcm43xx module, and switched over to my
prism54 card in order to get net access.
This was all on wireless-dev as of yesterday with the 1G limit patch
from this thread.
Let me know if there's anything I can try, I'd love to get this working
properly.
Daniel
^ permalink raw reply
* Fw: [Bugme-new] [Bug 6720] New: mga framebuffer flickers after upgrading to 2.6.17
From: Andrew Morton @ 2006-06-19 23:09 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: Petr Vandrovec
Begin forwarded message:
Date: Mon, 19 Jun 2006 13:42:51 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6720] New: mga framebuffer flickers after upgrading to 2.6.17
http://bugzilla.kernel.org/show_bug.cgi?id=6720
Summary: mga framebuffer flickers after upgrading to 2.6.17
Kernel Version: 2.6.17
Status: NEW
Severity: normal
Owner: ak@suse.de
Submitter: markus.gapp@ktv-one.at
Most recent kernel where this bug did not occur: 2.6.16.20
Distribution: gentoo -- vanilla sources
Hardware Environment: dual opteron, mga g550, lcd connected via dvi
Software Environment: framebuffer console
Problem Description: after upgrading to 2.6.17 on an opteron smp machine
(x86_64 kernel) with a mga g550 vga several dots around letters on a
framebuffer console are flickering. matroxfb is compiled as a module.
this also happens to an X server using mga and fbhw submodule.
Steps to reproduce:
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: [PATCH] entry_data
From: Massimiliano Hofer @ 2006-06-19 23:05 UTC (permalink / raw)
To: netfilter-devel; +Cc: Patrick McHardy
In-Reply-To: <4496E2B2.6010209@trash.net>
On Monday 19 June 2006 7:45 pm, Patrick McHardy wrote:
> > This leads me to a more radical proposal. Is there any reason we don't
> > have a general way to negate matches? It wouldn't be too difficult and we
[...]
> It would be useful for some matches (basically those that only check
> a single attribute), others may want to combine negated matching
> on some attributes with non-negated matching on others. In these
I agree with you.
Let's suppose we want to implement this feature and we don't want to cause
major breakage. I can't find a suitable bit in xt_entry_match, but we could
define a "wrapper match". We could set u.name to "!" or something similar and
data to:
struct {
int invert;
struct xt_entry_match nested_xt_entry_match;
};
Similar wrappers would effectively transform a simple linear data structure in
a tree, so I don't think this is a thing we should endorse lighly.
Any better ideas?
> ... my opinion is that if the packet doesn't have a mark the expression
> ! <mark> is clearly true. Another questionable behaviour in my opinion
> is using hotdrop to drop packets which are missing the information we
> are interested in. The same argument holds here, if something is not
> present, it just doesn't match. And negated it does match. The least
> we should do is have consistent behaviour, so either connmark should
> also use hotdrop, or nobody should (well, except for the few cases
> where it is unsed in case of memory allocation failures and things
> like that).
I agree.
--
Saluti,
Massimiliano Hofer
Nucleus
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] mips-user socket-related syscall support
From: Fabrice Bellard @ 2006-06-19 22:52 UTC (permalink / raw)
To: ml-qemu; +Cc: qemu-devel
In-Reply-To: <449667B1.5070300@twilight-hall.net>
Another point is that doing:
+ target_long args[6];
+
+ tputl(args, arg1);
+ tputl(args+1, arg2);
+ tputl(args+2, arg3);
+ tputl(args+3, arg4);
+ tputl(args+4, arg5);
+ tputl(args+5, arg6);
at the start of every syscall is not acceptable. You should add a
specific socket call wrapper which takes arg1... arg6 as arguments.
Regards,
Fabrice.
Raphaël Rigo wrote:
> Hello,
> this patch is a revamped version of the one I posted about 2 months ago,
> it is much better. It implements the syscalls related to sockets on the
> MIPS platform (because it has no "socketcall" syscall). I had to create
> a "socket.h" file defining the constants for the targets because MIPS
> doesn't have the same as every other platform.
>
> The calls implemented are : accept, bind, connect, getpeername,
> getsockname, listen, recv, recvfrom, recvmsg, send, sendmsg, sendto,
> shutdown, socket, socketpair.
>
> Combined with the other patch I just posted (signal handling), qemu-mips
> is now capable of running a webserver (which is very nice :)
>
> Please consider it for inclusion into mainline.
>
> Raphaël Rigo
^ permalink raw reply
* Re: Linux 2.4.33-rc1
From: Willy Tarreau @ 2006-06-19 23:00 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Grant Coady, linux-kernel, Al Viro
In-Reply-To: <20060619220405.GA16251@dmt>
On Mon, Jun 19, 2006 at 07:04:05PM -0300, Marcelo Tosatti wrote:
> Think this is the right thing to do, except that it must be guaranteed
> that the inode struct won't be freed in the meantime, need to grab a
> reference to it.
OK, I believe it will be right this time. I took inspiration from your
precedent patch to sys_unlink().
diff --git a/fs/namei.c b/fs/namei.c
index 42cce98..374b767 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1478,12 +1478,16 @@ exit:
int vfs_unlink(struct inode *dir, struct dentry *dentry)
{
int error;
+ struct inode *inode;
error = may_delete(dir, dentry, 0);
if (error)
return error;
- double_down(&dir->i_zombie, &dentry->d_inode->i_zombie);
+ inode = dentry->d_inode;
+ atomic_inc(&inode->i_count);
+ double_down(&dir->i_zombie, &inode->i_zombie);
+
error = -EPERM;
if (dir->i_op && dir->i_op->unlink) {
DQUOT_INIT(dir);
@@ -1495,7 +1499,9 @@ int vfs_unlink(struct inode *dir, struct
unlock_kernel();
}
}
- double_up(&dir->i_zombie, &dentry->d_inode->i_zombie);
+ double_up(&dir->i_zombie, &inode->i_zombie);
+ iput(inode);
+
if (!error) {
d_delete(dentry);
inode_dir_notify(dir, DN_DELETE);
BTW, I might be wrong because my knowledge in this area is rather poor, but
I now believe that your previously proposed fix below indeed is not needed
at all :
> diff --git a/fs/namei.c b/fs/namei.c
> index 42cce98..69da199 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1509,6 +1511,7 @@ asmlinkage long sys_unlink(const char *
> char * name;
> struct dentry *dentry;
> struct nameidata nd;
> + struct inode *inode = NULL;
>
> name = getname(pathname);
> if(IS_ERR(name))
> @@ -1527,11 +1530,16 @@ asmlinkage long sys_unlink(const char *
> /* Why not before? Because we want correct error value */
> if (nd.last.name[nd.last.len])
> goto slashes;
---- from here ----
> + inode = dentry->d_inode;
> + if (inode)
> + atomic_inc(&inode->i_count);
> error = vfs_unlink(nd.dentry->d_inode, dentry);
> exit2:
> dput(dentry);
> }
> up(&nd.dentry->d_inode->i_sem);
> + if (inode)
> + iput(inode);
---- to here ----
I believe that nd.dentry->d_inode cannot vanish because it is protected by the
down(->i_sem) before and the up(->i_sem) after. Am I right or am I missing
something important ?
> exit1:
> path_release(&nd);
> exit:
Thanks,
Willy
^ permalink raw reply related
* Re: [RFC] Interrupt mapping documentation
From: Jon Loeliger @ 2006-06-19 23:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Becky Bruce, linuxppc-dev list
In-Reply-To: <3E324A7E-388E-4917-B380-B0831A5F9D19@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
> > Wow, you've been busy! This mostly looks good to me - just a few
> > *minor* comments below. I've snipped out parts I'm not commenting on,
> > to shrink this email down.....
>
> Yeah. I've got some nits too, although mostly spelling. Will get to
> those later, if I find the time :-)
BTW, Becky sent him an off-list correction for a series
of spelling and grammar related changes. You might wait
for that... :-)
> Inheritance from the parent does not exist, in real OF. Absence of
> #address-cells means "default to 2". This needs to be fixed in DTC.
>
> [...]
>
> Just *require* #address-cells for everything with addressable sub-nodes,
> at least in DTC. Doesn't cost much, and no confusion anymore.
Woot! Send me a patch! :-)
jdl
^ permalink raw reply
* Re: [Bugme-new] [Bug 6698] New: unregister_netdevice hangs indefinitely from /proc/sys/net/ipv6/conf/all/forwarding
From: Andrew Morton @ 2006-06-19 23:06 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon@kernel-bugs.osdl.org, kernelbmw
In-Reply-To: <200606161620.k5GGKagU011416@fire-2.osdl.org>
bugme-daemon@bugzilla.kernel.org wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6698
>
> Summary: unregister_netdevice hangs indefinitely from
> /proc/sys/net/ipv6/conf/all/forwarding
> Kernel Version: 2.6.17-rc6
> Status: NEW
> Severity: normal
> Owner: yoshfuji@linux-ipv6.org
> Submitter: kernelbmw@lsmod.de
>
>
> Most recent kernel where this bug did not occur: none known (yet)
> Distribution: reproduced on Debian/stable, SuSE/10.0, SuSE/10.1
> Hardware Environment: reproduced on UML, i386, x86/64
> Software Environment: reproduced with openvpn and UML tap devices
> Problem Description: after adding IPv6 to my previously working openvpn
> tunneling setup, a (really old) IPv6-related bug started to occurr:
> http://lkml.org/lkml/2003/8/21/1
> I also reproduced this bug with kernel 2.6.15.1(vanilla,uml) and
> 2.6.16.13(SuSE-version,x86/64) and linux-2.6.13 (SuSE-version,i386)
>
> Steps to reproduce:
> echo 0 > /proc/sys/net/ipv6/conf/all/forwarding # this is important initialization
>
> Have (any version of) openvpn open a tunnel using a tap (virtual ethernet)
> device. In the "up" script do:
> echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
> this can be easily tested with these lines:
> apt-get install openvpn
> modprobe tun
> mknod /dev/net/tun c 10 200
> echo 0 > /proc/sys/net/ipv6/conf/all/forwarding
> echo "echo 1 > /proc/sys/net/ipv6/conf/all/forwarding" > /tmp/up ; chmod a+x /tmp/up
> openvpn --dev-type tap --remote tunnel.lsmod.de 5003 --ifconfig 10.9.0.2
> 255.255.255.0 --dev-node /dev/net/tun --up /tmp/up
> # at this point you can verify your tunnel setup by ping 10.9.0.1
> # on the server I have this: openvpn --dev-type tap --ifconfig 10.9.0.1
> 255.255.255.0 --port 5003 --dev-node /dev/net/tun --float
> # you need UDP port 5003 to pass through your firewall for this
>
>
> Alternatively get an user-mode-linux(UML) binary and do something along the
> lines of:
> apt-get install uml-utilities
> TAP=`tunctl -b`
> ifconfig $TAP 192.168.121.1 netmask 255.255.255.252
> echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
> /path/to/linux eth0=tuntap,$TAP ... # booting up to the point where the tap dev
> is really bound (at "ifconfig eth0 192.168.121.2" within the UML)
> tunctl -d $TAP
>
>
> After 20 seconds kill the openvpn or linux process.
> This hangs indefinitely, leaving the openvpn process in "D" state.
> syslog states every 10 secs:
> unregister_netdevice: waiting for tap0 to become free. Usage count = 1
>
> The kernel will then hang "ifconfig" and "ip" commands, probably because the
> waiting-for-tap0 still holds a mutex.
>
> After a dozen reboots of trying I found a work-around: replacing the critical
> line with
> (sleep 2 ; echo 1 > /proc/sys/net/ipv6/conf/all/forwarding )&
>
> A sleep 1 does not suffice.
> Doing the echo before calling openvpn also works fine, so there seems to be a
> timing problem or race condition during initialization of the IPv6 on the newly
> created tap0 device.
>
Thought to be an ipv6 refcount leak.
^ permalink raw reply
* Just your honesty and sincerity is all I need.
From: Wylo Wylos Jr @ 2006-06-19 22:56 UTC (permalink / raw)
Hello My Friend.
As you read through my message, I do not want you to
feel pity or sorry for me, for I believe someday, somehow, we will all
surely die, this is about mine, and a last wish.
My name is Mr.Wylo
Wylos Jr, a Citizen of the Republic of Mauritius, I have cancer and it
is terminal, medical science can not do anything for me at this stage.
I believe in miracles because I believe in GOD, however I prefer to
pass on at this stage since I am bed ridden and in constant in. Having
known my condition I decided to entrust some fund I have ( USD 2
Million) deposited in Europe to either a philanthropic organization or
devoted individual that
will utilize this money the way I am going to
instructs.
10% of the money goes to you to ensure that you are
prepared for the task ahead, the balance 90% of this money will be used
in all sincerity to fund philanthropic organization, orphanages. I am
taking this decision because I don't have any child or devoted
relations whose behavior has left much to be desired and above all I
don't want a situation where this money will be used in an unGodly
manner, hence this bold decision. Since my health
is retrogressing by
the minute, you will have to send your; POSTAL ADDRESS, CONTACT PHONE
NUMBER AND FAX and a little details about yourself, because I got your
address from the Internet after a thorough search.
With the
information, I will make arrangement to prepare the Authorization
through an Attorney for you to get Possession of the Deposit. I will
give you the name and contact of the Deposit company where the money is
lodged in Europe thereafter, so you can claim the funds. Until I hear
from you, I pray that this letter bring you and your family good
tidings.
Reply via email address
God be with you.
Mr. Wylo
Wylos Jr
^ permalink raw reply
* Re: [Qemu-devel] SystemC hw simulation in qemu
From: Fabrice Bellard @ 2006-06-19 22:54 UTC (permalink / raw)
To: ale.corradi; +Cc: qemu-devel
In-Reply-To: <b921df970606180159u53782d14jcbf1165abb894f34@mail.gmail.com>
Alessandro Corradi wrote:
> Hi all,
> I've tried to create my simple hw and it's ok. Now my teacher tells me
> that i must use a hw description written in SystemC and plug in Qemu.
> Have you got any idea to do it? Can somebody link me to documents where
> I can find info?
Hi,
If you do that I am interested to see the results. Use a simple device
such as the serial port (hw/serial.c) as an example.
Regards,
Fabrice.
^ 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.