Re: Support for i386 PATs
Mikael Pettersson wrote: 3) Many Intel processors, including at least most P6s and probably also some P4s, have an erratum which effectively halves the number of available PAT entries, forcing an OS to make the low 4 and upper 4 PAT entries identical. I don't know if 4 PAT types suffice for the kinds of uses people have in mind. But support for PAT would either have to restrict itself to only 4 PAT types, or ensure that it is only enabled on new enough processors where it actually works. You will need to read all available Intel errata sheets (spec updates) to determine which processors are affected and which are OK. There aren't really that many useful caching types, so it probably doesn't matter all that much. The types that matters most are WB, WC, and UC. The fourth one could be WT, or it could be UC- (however, UC- can *always* be emulated by simply having the kernel being aware of the MTRR settings.) -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The mbox format archives of linux-kernel are gone.
Andrew Morton wrote: On Sat, 27 Jan 2007 20:36:31 -0500 Rob Landley <[EMAIL PROTECTED]> wrote: > I would like to find the history of linux-kernel in mbox format. ... I have them going back to October 2000. I guess I can upload them after various bandwidth-using offspring have finished playing counterstrike and WoW. Any chance to have anything like an auto-update mbox archive of LKML? Would be nice for people not permanently subscribed to LKML. Regards Dirk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc6-mm1
Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc6-mm1/ will appear one day at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm1/ - Added the "IPWireless 3G PCMCIA Network Driver" tree as git-ipwireless_cs.patch (Jiri Kosina <[EMAIL PROTECTED]>) - Added the IDE development tree. It's a quilt-style tree at http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/patches/ (Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>) - google have a position open for a public kernel bug manager. See http://www.google.com/support/jobs/bin/answer.py?answer=53317 This will involve working out of the Mountain View offices alongside myself, keeping track of the status of bugs in Linus's tree. If you're qualified && interested, feel free to contact me. - It seems that people have been busy creating the need for this. I had to apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation errors. And a number of patches were dropped due to no-compile or to runtime errors. Heaven knows how many runtime bugs were added. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Semi-daily snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.20-rc4-mm1: origin.patch git-acpi.patch git-ibm-acpi.patch git-alsa.patch git-agpgart.patch git-arm.patch git-avr32.patch git-cpufreq.patch git-powerpc.patch git-drm.patch git-dvb.patch git-gfs2-nmw.patch git-hid.patch git-ieee1394.patch git-infiniband.patch git-input.patch git-jfs.patch git-libata-all.patch git-lxdialog.patch git-mips.patch git-mmc.patch git-mtd.patch git-ubi.patch git-netdev-all.patch git-ioat.patch git-ocfs2.patch git-pciseg.patch git-s390.patch git-sh.patch git-scsi-misc.patch git-scsi-rc-fixes.patch git-block.patch git-qla3xxx.patch git-unionfs.patch git-watchdog.patch git-ipwireless_cs.patch git-cryptodev.patch git-gccbug.patch git trees. -sched-tasks-cannot-run-on-cpus-onlined-after-boot.patch -increment-pos-before-looking-for-the-next-cap-in-__pci_find_next_ht_cap.patch -fix-sparsemem-on-cell.patch -qconf-fix-sigsegv-on-empty-menu-items.patch -rtc-sh-correctly-report-rtc_wkalrmenabled.patch -change-cpu_up-and-co-from-__devinit-to-__cpuinit.patch -kdump-documentation-update-for-2620.patch -i386-sched_clock-using-init-data-tsc_disable-fix.patch -md-pass-down-bio_rw_sync-in-raid110.patch -kvm-add-vm-exit-profiling.patch -nfs-fix-race-in-nfs_release_page.patch -really-fix-funsoft-driver.patch -revert-bd_mount_mutex-back-to-a-semaphore.patch -intel-rng-workarounds.patch -fix-hwrng-built-in-initcalls-priority.patch -fix-typo-in-geode_configre-cyrixc.patch -fd_zero-build-fix.patch -revert-nmi_known_cpu-check-during-boot-option-parsing.patch -blockdev-direct_io-fix-signedness-bug.patch -submitchecklist-update.patch -paravirt-mark-the-paravirt_ops-export-internal.patch -kvm-make-sure-there-is-a-vcpu-context-loaded-when.patch -kvm-fix-race-between-mmio-reads-and-injected-interrupts.patch -kvm-x86-emulator-fix-bit-string-instructions.patch -kvm-fix-asm-constraints-with-config_frame_pointer=n.patch -kvm-fix-bogus-pagefault-on-writable-pages.patch -rtc-sh-act-on-rtc_wkalrmenabled-when-setting-an-alarm.patch -fix-blk_direct_io-bio-preparation.patch -tlclk-bug-fix-misc-fixes.patch -tlclk-bug-fix-misc-fixes-tidy.patch -reiserfs-avoid-tail-packing-if-an-inode-was-ever-mmapped.patch -cifs-sprintf-fix.patch -cifs-remove-2-unneeded-kzalloc-casts.patch -powerpc-use-is_init.patch -fix-gregkh-driver-driver-core-fix-race-in-sysfs-between-sysfs_remove_file-and-read-write.patch
Re: definite OMAP1610_IR-related typo
Robert P. J. Day wrote at LKML: > not sure what to do with this, it's all yours: > > == OMAP1610_IR == > ./arch/arm/mach-omap1/devices.c:#if defined(CONFIG_OMAP1610_IR) || > defined(CONFIG_OMAP161O_IR_MODULE) > == OMAP161O_IR == > ./arch/arm/mach-omap1/devices.c:#if defined(CONFIG_OMAP1610_IR) || > defined(CONFIG_OMAP161O_IR_MODULE) > > note first that one of those config vars has an "oh" while the other > has a *zero*. i'm pretty sure that's bad. > > in any event, there's no such config variable of *either* spelling > in any Kconfig file, but there *is* a more all-encompassing > CONFIG_OMAP16XX confguration setting. This is fixed in recent OMAP git tree and OMAP patches we prepared for upstream. Can you try OMAP patches 4113, 4114, 4115 and 4116 to be found in RMKs patch system [1]? Or, even better, use current OMAP git [2]? Regards Dirk P.S. #1: Would be nice to CC OMAP list [3] next time as well. P.S. #2: Sorry if mail references are wrong, I'm currently not subscribed to LKML. [1] http://www.arm.linux.org.uk/developer/patches/section.php?section=0 [2] http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=summary [3] http://linux.omap.com/mailman/listinfo/linux-omap-open-source - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drop page cache of a single file
Zhang, Yanmin wrote: > Currently, by /proc/sys/vm/drop_caches, applications could drop pagecache, > slab(dentries and inodes), or both, but applications couldn't choose to > just drop the page cache of one file. An user of VOD (Video-On-Demand) > needs this capability to have more detailed control on page cache release. > > Below patch against 2.6.19 implements it. > > Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]> > > --- > > diff -Nraup linux-2.6.19/Documentation/filesystems/proc.txt > linux-2.6.19_dropcache/Documentation/filesystems/proc.txt > --- linux-2.6.19/Documentation/filesystems/proc.txt 2006-12-08 > 15:32:44.0 +0800 > +++ linux-2.6.19_dropcache/Documentation/filesystems/proc.txt 2006-12-28 > 10:20:39.0 +0800 > @@ -1320,6 +1320,8 @@ To free dentries and inodes: > echo 2 > /proc/sys/vm/drop_caches > To free pagecache, dentries and inodes: > echo 3 > /proc/sys/vm/drop_caches > +To free the pagecache of one file: > + echo "4 /path/to/filename" > /proc/sys/vm/drop_caches > > As this is a non-destructive operation and dirty objects are not freeable, > the > user should run `sync' first. "sync" is the most time consuming operation. Clean pagecache pages are immediately reclaimable... they are actually free pages. Writing out dirty pages consumes time. Hence this approach may not provide the required performance benefits since only clean pagecache pages are marked free. fadvise approach would provide similar behavior. --Vaidy [snip] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc6-rt2 - SMP/x86 -- questions about .config selection
Hi Ingo, I did boot with (almost) no problems. Here is ps ax info:- PID TTY STAT TIME COMMAND 1 ?Ss 0:00 init [5] 2 ?S 0:00 [migration/0] 3 ?S 0:00 [posix_cpu_timer] 4 ?S 0:00 [softirq-high/0] 5 ?S 0:00 [softirq-timer/0] 6 ?S 0:00 [softirq-net-tx/] 7 ?S 0:00 [softirq-net-rx/] 8 ?S 0:00 [softirq-block/0] 9 ?S 0:00 [softirq-tasklet] 10 ?S 0:00 [softirq-sched/0] 11 ?S 0:00 [softirq-hrtimer] 12 ?S 0:00 [softirq-rcu/0] 13 ?S< 0:00 [desched/0] 14 ?S 0:00 [migration/1] 15 ?S 0:00 [posix_cpu_timer] 16 ?S 0:00 [softirq-high/1] 17 ?S 0:00 [softirq-timer/1] 18 ?S 0:00 [softirq-net-tx/] 19 ?S 0:00 [softirq-net-rx/] 20 ?S 0:00 [softirq-block/1] 21 ?S 0:00 [softirq-tasklet] 22 ?S 0:00 [softirq-sched/1] 23 ?S 0:00 [softirq-hrtimer] 24 ?S 0:00 [softirq-rcu/1] . . Here is the interrupt info:- CPU0 CPU1 0:354 0 IO-APIC-edge timer 1:361 0 IO-APIC-edge i8042 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 7 0 IO-APIC-edge i8042 14: 1985 0 IO-APIC-edge ide0 16: 13042 0 IO-APIC-fasteoi uhci_hcd:usb4, HDA Intel, [EMAIL PROTECTED]::00:02.0 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 19: 11520 0 IO-APIC-fasteoi uhci_hcd:usb2, libata 20: 2 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5 21:515 0 IO-APIC-fasteoi eth0 NMI: 0 0 LOC: 23573 24545 ERR: 0 MIS: 0 I did get REMINDER, the following debugging options are turned on in your .config: CONFIG_CRITICAL_IRQSOFF_TIMING CONFIG_FUNCTION_TRACE This I have understood, no issues here. There is some confusion for me while configuring a rt kernel & proceeding for experiments. I did choose the following:- NO_HZ=y HIGH_RES_TIMERS=y SMP=y PREEMPT_VOLUNTARY=y PREEMPT_SOFTIRQS=y PREEMPT_HARDIRQS=y SPINLOCK_BKL=y CLASSIC_RCU=y SCHED_SMT=y IRQBALANCE=y HZ_1000=y #1 Is this correct to say PREEMPT_VOLUNTARY=y for rt on this desktop PC? #2 I am not clear about IRQ config selection (which one should be enable/disable for a PC, I did select all as shown in the above config). Any suggestion? #3 Any other parameter(s) I need to enable/disable to get better results? (did disable APM) Thanks, ~Su37 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The mbox format archives of linux-kernel are gone.
On Sat, 27 Jan 2007 20:36:31 -0500 Rob Landley <[EMAIL PROTECTED]> wrote: > I would like to find the history of linux-kernel in mbox format. I thought > it > was under http://kernel.org/pub but apparently not. > > Rooting around at http://vger.kernel.org/vger-lists.html#linux-kernel points > to a bunch of stale links. (The alaska archive is gone, the helsinki one > stopped in 2004, the indiana one mbox link is 404...) > > The linux-kernel faq's archives entry points to web archives, where I can > look > up one post at a time. I could do that through google groups. I used to be > able to see "month at a time" indexes at lists.insecure.org, but that took > its' linux-kernel archive down last year. > > I found Zach Brown asking for them and getting them anonymously sent to him, > but no download link and one reason I want them is Kernel Traffic stopped > updating in 2005 and I've fallen behind on the list again. > > This link: > http://mailman.linuxchix.org/pipermail/techtalk/2005-February/019865.html > > Suggests that mbox files may be found on lkml.org, which doesn't seem to be > true (not on their current main page, nor archive.org, nor any browsing > around I've managed to do...) > > Does anyone have any suggestions? Google is being unhelpful... I have them going back to October 2000. I guess I can upload them after various bandwidth-using offspring have finished playing counterstrike and WoW. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] AGPGART compat ioctl
Hi Dave,
The following video card requires the agpgart driver ioctl
interface in order to detect video memory.
00:02.0 VGA compatible controller: Intel Corporation Mobile
945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
Tested on a Thinkpad Z61t, Xorg.0.log from a 32bit debian Xorg is at;
http://montezuma.homeunix.net/Xorg.0.log
Cheers,
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
drivers/char/agp/frontend.c | 253
include/linux/agpgart.h | 61 ++
2 files changed, 314 insertions(+)
Index: linux-2.6.20-rc4-mm1/include/linux/agpgart.h
===
RCS file: /home/cvsroot/linux-2.6.20-rc4-mm1/include/linux/agpgart.h,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 agpgart.h
--- linux-2.6.20-rc4-mm1/include/linux/agpgart.h27 Jan 2007 22:04:06
- 1.1.1.1
+++ linux-2.6.20-rc4-mm1/include/linux/agpgart.h27 Jan 2007 22:41:23
-
@@ -114,6 +114,67 @@ typedef struct _agp_unbind {
#define AGPGART_MINOR 175
+#ifdef CONFIG_COMPAT
+#include
+
+#define AGPIOC_INFO32 _IOR (AGPIOC_BASE, 0, compat_uptr_t)
+#define AGPIOC_ACQUIRE32_IO (AGPIOC_BASE, 1)
+#define AGPIOC_RELEASE32_IO (AGPIOC_BASE, 2)
+#define AGPIOC_SETUP32 _IOW (AGPIOC_BASE, 3, compat_uptr_t)
+#define AGPIOC_RESERVE32_IOW (AGPIOC_BASE, 4, compat_uptr_t)
+#define AGPIOC_PROTECT32_IOW (AGPIOC_BASE, 5, compat_uptr_t)
+#define AGPIOC_ALLOCATE32 _IOWR(AGPIOC_BASE, 6, compat_uptr_t)
+#define AGPIOC_DEALLOCATE32 _IOW (AGPIOC_BASE, 7, compat_int_t)
+#define AGPIOC_BIND32 _IOW (AGPIOC_BASE, 8, compat_uptr_t)
+#define AGPIOC_UNBIND32 _IOW (AGPIOC_BASE, 9, compat_uptr_t)
+
+struct agp_info32 {
+ struct agp_version version; /* version of the driver*/
+ u32 bridge_id; /* bridge vendor/device */
+ u32 agp_mode; /* mode info of bridge */
+ compat_long_t aper_base;/* base of aperture */
+ compat_size_t aper_size;/* size of aperture */
+ compat_size_t pg_total; /* max pages (swap + system)*/
+ compat_size_t pg_system;/* max pages (system) */
+ compat_size_t pg_used; /* current pages used */
+};
+
+/*
+ * The "prot" down below needs still a "sleep" flag somehow ...
+ */
+struct agp_segment32 {
+ compat_off_t pg_start; /* starting page to populate*/
+ compat_size_t pg_count; /* number of pages */
+ compat_int_t prot; /* prot flags for mmap */
+};
+
+struct agp_region32 {
+ compat_pid_t pid; /* pid of process */
+ compat_size_t seg_count;/* number of segments */
+ struct agp_segment32 *seg_list;
+};
+
+struct agp_allocate32 {
+ compat_int_t key; /* tag of allocation*/
+ compat_size_t pg_count; /* number of pages */
+ u32 type; /* 0 == normal, other devspec */
+ u32 physical; /* device specific (some devices
+* need a phys address of the
+* actual page behind the gatt
+* table)*/
+};
+
+struct agp_bind32 {
+ compat_int_t key; /* tag of allocation*/
+ compat_off_t pg_start; /* starting page to populate*/
+};
+
+struct agp_unbind32 {
+ compat_int_t key; /* tag of allocation*/
+ u32 priority; /* priority for paging out */
+};
+#endif /* CONFIG_COMPAT */
+
struct agp_info {
struct agp_version version; /* version of the driver*/
u32 bridge_id; /* bridge vendor/device */
Index: linux-2.6.20-rc4-mm1/drivers/char/agp/frontend.c
===
RCS file: /home/cvsroot/linux-2.6.20-rc4-mm1/drivers/char/agp/frontend.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 frontend.c
--- linux-2.6.20-rc4-mm1/drivers/char/agp/frontend.c27 Jan 2007 22:03:38
- 1.1.1.1
+++ linux-2.6.20-rc4-mm1/drivers/char/agp/frontend.c27 Jan 2007 22:41:44
-
@@ -1039,6 +1039,256 @@ ioctl_out:
return ret_val;
}
+#ifdef CONFIG_COMPAT
+static int compat_agpioc_info_wrap(struct agp_file_private *priv, void __user
*arg)
+{
+ struct agp_info32 userinfo;
+ struct agp_kern_info kerninfo;
+
+ agp_copy_info(agp_bridge, );
+
+ userinfo.version.major = kerninfo.version.major;
+ userinfo.version.minor = kerninfo.version.minor;
+ userinfo.bridge_id = kerninfo.device->vendor |
+ (kerninfo.device->device << 16);
+ userinfo.agp_mode = kerninfo.mode;
+ userinfo.aper_base =
Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
Theodore Tso wrote: FYI, the anticipated rooms costs at Cambridge will be 60-70 pounds, and this is for single rooms with private baths --- and just two weeks ago I needed to tell this to sooth a worried corporate budget maven that combined with cheaper flights to Amsterdam and then flying Ryan Air to Stansted, that no really, holding a KS outside the North America wouldn't break their travel budget. Well just a footnote here, but anyone doing that kind of connection for a meeting is clearly ready for the rubber padded hospital ... but thats besides the point here. Fact is that as long as the meeting starts before ~ June 15 or after September 15, avoiding the peak season, airfare aren't that bad. It's the insanity of running OLS during July that really kicks people's travel budgets in the shins . Outside of this peak season they tend to drop by 30-50%. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
On 28/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
--- linux-2.6.20-rc6-mm1/block/elevator.c.dist 2007-01-26 14:30:36.0
-0500
+++ linux-2.6.20-rc6-mm1/block/elevator.c 2007-01-27 19:57:02.0
-0500
@@ -604,12 +604,6 @@ void elv_insert(request_queue_t *q, stru
*/
rq->cmd_flags | REQ_SOFTBARRIER;
- /*
-* Most requeues happen because of a busy condition,
-* don't force unplug of the queue for that case.
-*/
- unplug_it 0;
-
if (q->ordseq 0) {
list_add(>queuelist, >queue_head);
break;
(How did *that* one manage to compile for anybody??!?)
I have fixed this in my local tree, but I didn't send a patch because
Andrew has sent a git-block-borkage.patch three minutes earlier.
After all that, I finally got a clean compile Maybe later I'll get brave
and actually try to boot it. :)
Good luck :)
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
On Sat, 27 Jan 2007 13:41:16 PST, Andrew Morton said:
> > > On 26/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >> The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
> > >>
> > >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz
> I have everything compiling now, mostly. The number of fixes which were
> needed was just extraordinary. I'm thinking about making changes...
Another one - I can't get this to build for x86_64. (Skipping over all the
already-mentioned build errors that others have already reported...)
First, I had to do some ad-crock hacking of Kconfig files to get kernel/timer.c
to build right, because otherwise it didn't include any of the defines in
include/kernel/clockchips.c so CLOCK_EVT_NOTIFY_RESUME wasn't defined (either
that, or a #ifdef for GENERIC_TIME had its #endif land in the wrong place?)
--- linux-2.6.20-rc6-mm1/arch/x86_64/Kconfig.dist 2007-01-26
14:30:53.0 -0500
+++ linux-2.6.20-rc6-mm1/arch/x86_64/Kconfig2007-01-27 07:14:22.0
-0500
@@ -32,6 +32,14 @@ config GENERIC_TIME_VSYSCALL
bool
default y
+config GENERIC_CLOCKEVENTS
+ bool
+ default y
+
+config GENERIC_CLOCKEVENTS_BROADCAST
+ bool
+ default y
+
config ZONE_DMA32
bool
default y
@@ -126,6 +134,8 @@ source "init/Kconfig"
menu "Processor type and features"
+source "kernel/time/Kconfig"
+
choice
prompt "Subarchitecture Type"
default X86_PC
And even after that, I hit this:
CC kernel/time/clocksource.o
In file included from kernel/time/clocksource.c:31:
include/linux/tick.h:45: error: field sched_timer has incomplete type
make: *** [kernel/time/clocksource.o: Error 1
--- linux-2.6.20-rc6-mm1/kernel/time/clocksource.c.dist 2007-01-27
19:36:31.0 -0500
+++ linux-2.6.20-rc6-mm1/kernel/time/clocksource.c 2007-01-27
19:36:03.0 -0500
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
/* XXX - Would like a better way for initializing curr_clocksource */
Then we live long enough to hit this:
CC block/elevator.o
block/elevator.c: In function elv_insert:
block/elevator.c:611: error: unplug_it undeclared (first use in this function)
--- linux-2.6.20-rc6-mm1/block/elevator.c.dist 2007-01-26 14:30:36.0
-0500
+++ linux-2.6.20-rc6-mm1/block/elevator.c 2007-01-27 19:57:02.0
-0500
@@ -604,12 +604,6 @@ void elv_insert(request_queue_t *q, stru
*/
rq->cmd_flags |= REQ_SOFTBARRIER;
- /*
-* Most requeues happen because of a busy condition,
-* don't force unplug of the queue for that case.
-*/
- unplug_it = 0;
-
if (q->ordseq == 0) {
list_add(>queuelist, >queue_head);
break;
(How did *that* one manage to compile for anybody??!?)
After all that, I finally got a clean compile Maybe later I'll get brave
and actually try to boot it. :)
pgp4eKojzX33i.pgp
Description: PGP signature
Re: [patch 00/46] High resolution timer / dynamic tick update
On Tue, 23 Jan 2007 22:00:55 - Thomas Gleixner <[EMAIL PROTECTED]> wrote: > This is a full replacement queue for the high resolution timer / dynamic > ticks implemementation in -mm. The Vaio broke again. Seems to hang permanently the first time it tries to sleep. The cursor doesn't flash. Adding "clock=pit" doesn't fix it. I'm disinclined to bisect it since the patch series fails to compile at practically all bisections points. I'll drop all the patches, which means I drop John's vsyscall patches and his x86_64 conversion as well. I guess in a pinch we could go back to the 2.6.20-rc4-mm1 patches if we want to get something into 2.6.21. Even those diverged a lot after they were reviewed, but they do appear to work. I don't have a clue what's in this new patchset and as far as I'm concerned, we're right back to square one, sorry. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-rc6-mm1 # Sat Jan 27 17:55:01 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y # CONFIG_IKCONFIG is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y CONFIG_TOSHIBA=m CONFIG_I8K=m # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware
Re: [PATCH 2.6.20-rc5 1/4] atl1: unconditionally enable MSI
The subject line on all four of the current crop of atl1 patches is incorrect; they were generated against *2.6.20-rc6*, not rc5. I apologize for the error. Jay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] high_res_timers: precisely update_process_times; Re: [patch 36/46] tick-management: dyntick / highres functionality
Am Dienstag, 23. Januar 2007 23:01 schrieb Thomas Gleixner:
>
> Add functions to provide dynamic ticks and high resolution timers.
> The code which keeps track of jiffies and handles the long idle
> periods is shared between tick based and high resolution timer based
> dynticks. The dyntick functionality can be disabled on the kernel
> commandline. Provide also the infrastructure to support high resolution
> timers.
cpufreq_ondemand didn't work here on kernels 2.6.20-rc4-rt1 and above.
Following patch against 20-rc6-rt2 helps.
Karsten
---
From: Karsten Wiese <[EMAIL PROTECTED]>
high_res_timers: precisely update_process_times
Sometimes tick_sched_timer() calls tick_do_update_jiffies64() and
jiffies is updated by !=1.
Cope with these situations by splitting update_process_times() into
__update_process_times() and tick() and
exchanging call to update_process_times() from tick_sched_timer()
by calls to the splits.
Fixes cpufreq_ondemand going nuts here.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
--- rc6-rt2/include/linux/sched.h 2007-01-26 14:42:55.0 +0100
+++ rc6-rt2-kw/include/linux/sched.h2007-01-28 02:02:29.0 +0100
@@ -264,6 +264,13 @@ long io_schedule_timeout(long timeout);
extern void cpu_init (void);
extern void trap_init(void);
extern void update_process_times(int user);
+#ifdef CONFIG_HIGH_RES_TIMERS
+extern void __update_process_times(int user_tick, unsigned long ticks);
+extern void tick(int user_tick);
+#define NO_HIGH_RES_TIMERS_STATIC
+#else
+#define NO_HIGH_RES_TIMERS_STATIC static
+#endif
extern void scheduler_tick(void);
#ifdef CONFIG_GENERIC_HARDIRQS
diff -pur rc6-rt2/kernel/time/tick-sched.c rc6-rt2-kw/kernel/time/tick-sched.c
--- rc6-rt2/kernel/time/tick-sched.c2007-01-26 14:42:55.0 +0100
+++ rc6-rt2-kw/kernel/time/tick-sched.c 2007-01-28 01:45:14.0 +0100
@@ -41,9 +41,9 @@ struct tick_sched *tick_get_tick_sched(i
/*
* Must be called with interrupts disabled !
*/
-static void tick_do_update_jiffies64(ktime_t now)
+static unsigned long tick_do_update_jiffies64(ktime_t now)
{
- unsigned long ticks = 1;
+ unsigned long ticks = 0;
ktime_t delta;
/* Reevalute with xtime_lock held */
@@ -51,7 +51,7 @@ static void tick_do_update_jiffies64(kti
delta = ktime_sub(now, last_jiffies_update);
if (delta.tv64 >= tick_period.tv64) {
-
+ ticks = 1;
delta = ktime_sub(delta, tick_period);
last_jiffies_update = ktime_add(last_jiffies_update,
tick_period);
@@ -68,6 +68,7 @@ static void tick_do_update_jiffies64(kti
do_timer(ticks);
}
write_sequnlock(_lock);
+ return ticks;
}
/*
@@ -423,32 +424,36 @@ static enum hrtimer_restart tick_sched_t
ktime_t now = ktime_get();
/* Check, if the jiffies need an update */
- tick_do_update_jiffies64(now);
+ unsigned long ticks = tick_do_update_jiffies64(now);
/*
* Do not call, when we are not in irq context and have
* no valid regs pointer
*/
if (regs) {
- /*
-* When we are idle and the tick is stopped, we have to touch
-* the watchdog as we might not schedule for a really long
-* time. This happens on complete idle SMP systems while
-* waiting on the login prompt. We also increment the "start of
-* idle" jiffy stamp so the idle accounting adjustment we do
-* when we go busy again does not account too much ticks.
-*/
- if (ts->tick_stopped) {
- touch_softlockup_watchdog();
- ts->idle_jiffies++;
+ if (ticks) {
+ /*
+* When we are idle and the tick is stopped, we have to
touch
+* the watchdog as we might not schedule for a really
long
+* time. This happens on complete idle SMP systems while
+* waiting on the login prompt. We also increment the
"start of
+* idle" jiffy stamp so the idle accounting adjustment
we do
+* when we go busy again does not account too much
ticks.
+*/
+ if (ts->tick_stopped) {
+ touch_softlockup_watchdog();
+ ts->idle_jiffies++;
+ __update_process_times(user_mode(regs), 1);
+ } else
+ __update_process_times(user_mode(regs), ticks);
}
/*
-* update_process_times() might take tasklist_lock, hence
+* tick() might take tasklist_lock, hence
The mbox format archives of linux-kernel are gone.
I would like to find the history of linux-kernel in mbox format. I thought it was under http://kernel.org/pub but apparently not. Rooting around at http://vger.kernel.org/vger-lists.html#linux-kernel points to a bunch of stale links. (The alaska archive is gone, the helsinki one stopped in 2004, the indiana one mbox link is 404...) The linux-kernel faq's archives entry points to web archives, where I can look up one post at a time. I could do that through google groups. I used to be able to see "month at a time" indexes at lists.insecure.org, but that took its' linux-kernel archive down last year. I found Zach Brown asking for them and getting them anonymously sent to him, but no download link and one reason I want them is Kernel Traffic stopped updating in 2005 and I've fallen behind on the list again. This link: http://mailman.linuxchix.org/pipermail/techtalk/2005-February/019865.html Suggests that mbox files may be found on lkml.org, which doesn't seem to be true (not on their current main page, nor archive.org, nor any browsing around I've managed to do...) Does anyone have any suggestions? Google is being unhelpful... Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.20-rc5 3/4] atl1: properly use CONFIG_PM
From: Jay Cliburn <[EMAIL PROTECTED]>
Fix power management by properly using ifdef CONFIG_PM. Discovered by
and modification suggested by Andrew Morton.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index a9e02d1..1045325 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -2345,6 +2345,7 @@ static void __devexit atl1_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
}
+#ifdef CONFIG_PM
static int atl1_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct net_device *netdev = pci_get_drvdata(pdev);
@@ -2438,6 +2439,10 @@ static int atl1_resume(struct pci_dev *pdev)
return 0;
}
+#else
+#define atl1_suspend NULL
+#define atl1_resume NULL
+#endif
static struct pci_driver atl1_driver = {
.name = atl1_driver_name,
@@ -2446,10 +2451,8 @@ static struct pci_driver atl1_driver = {
.remove = __devexit_p(atl1_remove),
/* Power Managment Hooks */
/* probably broken right now -- CHS */
-#ifdef CONFIG_PM
.suspend = atl1_suspend,
.resume = atl1_resume
-#endif
};
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.20-rc5 4/4] atl1: incorporate reviewer comments
From: Jay Cliburn <[EMAIL PROTECTED]>
Incorporate reviewer comments from:
Randy Dunlap, http://lkml.org/lkml/2007/1/21/157
Arjan van de Ven, http://lkml.org/lkml/2007/1/22/21
Francois Romieu, http://lkml.org/lkml/2007/1/22/49
Fixup to follow coding standards, remove MII defines already found in
mii.h, remove unneeded code, make atl1_clear_phy_int() irq safe.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/atl1/atl1.h b/drivers/net/atl1/atl1.h
index 0b30e1c..cc18016 100644
--- a/drivers/net/atl1/atl1.h
+++ b/drivers/net/atl1/atl1.h
@@ -1,4 +1,4 @@
-/**
+/*
* Copyright(c) 2005 - 2006 Attansic Corporation. All rights reserved.
* Copyright(c) 2006 Chris Snook <[EMAIL PROTECTED]>
* Copyright(c) 2006 Jay Cliburn <[EMAIL PROTECTED]>
@@ -19,14 +19,13 @@
* 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.
- **/
+ */
#ifndef _ATL1_H_
#define _ATL1_H_
#include
#include
-#include
#include "atl1_hw.h"
@@ -37,6 +36,9 @@ int atl1_reset(struct atl1_adapter *adapter);
s32 atl1_setup_ring_resources(struct atl1_adapter *adapter);
void atl1_free_ring_resources(struct atl1_adapter *adapter);
+extern char atl1_driver_name[];
+extern char atl1_driver_version[];
+
struct atl1_adapter;
#define ATL1_MAX_INTR 3
@@ -53,17 +55,17 @@ struct atl1_adapter;
#define ATL1_TPD_DESC(R, i)ATL1_GET_DESC(R, i, struct tx_packet_desc)
#define ATL1_RRD_DESC(R, i)ATL1_GET_DESC(R, i, struct rx_return_desc)
-/**
+/*
* Some workarounds require millisecond delays and are run during interrupt
* context. Most notably, when establishing link, the phy may need tweaking
* but cannot process phy register reads/writes faster than millisecond
* intervals...and we establish link due to a "link status change" interrupt.
- **/
+ */
-/**
+/*
* wrapper around a pointer to a socket buffer,
* so a DMA handle can be stored along with the buffer
- **/
+ */
struct atl1_buffer {
struct sk_buff *skb;
u16 length;
@@ -78,7 +80,6 @@ struct atl1_tpd_ring {
dma_addr_t dma; /* physical adress of the descriptor ring */
u16 size; /* length of descriptor ring in bytes */
u16 count; /* number of descriptors in the ring */
-
u16 hw_idx; /* hardware index */
atomic_t next_to_clean;
atomic_t next_to_use;
@@ -105,12 +106,9 @@ struct atl1_rrd_ring {
};
struct atl1_ring_header {
- /* pointer to the descriptor ring memory */
- void *desc;
- /* physical adress of the descriptor ring */
- dma_addr_t dma;
- /* length of descriptor ring in bytes */
- unsigned int size;
+ void *desc; /* pointer to the descriptor ring memory */
+ dma_addr_t dma; /* physical adress of the descriptor ring */
+ unsigned int size; /* length of descriptor ring in bytes */
};
struct atl1_cmb {
@@ -143,16 +141,15 @@ struct atl1_sft_stats {
u64 tx_window_errors;
u64 tx_carrier_errors;
- u64 tx_pause; /* The number of Pause packet transmitted. */
- u64 excecol;/* The number of transmit packets aborted due
to excessive collisions. */
- u64 deffer; /* The number of packets transmitted that is
deferred. */
- u64 scc;/* The number of packets subsequently
transmitted successfully with a single prior collision. */
- u64 mcc;/* The number of packets subsequently
transmitted successfully with multiple prior collisions. */
- u64 latecol;/* The number of packets transmitted with late
collisions. */
- u64 tx_underun; /* The number of transmit packets aborted due
to transmit FIFO underrun, or TRD FIFO underrun */
- u64 tx_trunc; /* The number of transmit packets truncated due
to size exceeding MTU, regardless if it is truncated by Selene or not.
-* (The name is not really reflects the meaning
in this case here.) */
- u64 rx_pause; /* The number of Pause packet received. */
+ u64 tx_pause; /* num Pause packet transmitted. */
+ u64 excecol;/* num tx packets aborted due to excessive
collisions. */
+ u64 deffer; /* num deferred tx packets */
+ u64 scc;/* num packets subsequently transmitted
successfully w/ single prior collision. */
+ u64 mcc;/* num packets subsequently transmitted
successfully w/ multiple prior collisions. */
+ u64 latecol;/* num tx packets w/ late collisions. */
+ u64 tx_underun; /* num tx packets aborted due to transmit FIFO
underrun, or TRD FIFO underrun */
+ u64 tx_trunc; /* num tx packets truncated
Re: [PATCH] slab: cache_grow cleanup
On Tue, 9 Jan 2007 15:40:03 +0200 (EET) Pekka J Enberg <[EMAIL PROTECTED]> wrote: > The current implementation of cache_grow() has to either (1) use pre-allocated > memory for the slab or (2) allocate the memory itself which makes the error > paths messy. Move __GFP_NO_GROW and __GFP_WAIT processing to kmem_getpages() > and introduce a new __cache_grow() variant that expects the memory for a new > slab to always be handed over in the 'objp' parameter. This gets its local interrupt state mucked up. BUG: sleeping function called from invalid context at mm/slab.c:3038 in_atomic():0, irqs_disabled():1 no locks held by init/1. irq event stamp: 656902 hardirqs last enabled at (656901): [] mod_zone_page_state+0x4b/0x50 hardirqs last disabled at (656902): [] cache_alloc_refill+0x384/0x6a0 softirqs last enabled at (650628): [] unix_release_sock+0x67/0x220 softirqs last disabled at (650626): [] _write_lock_bh+0xe/0x40 [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] dump_stack+0x16/0x20 [] __might_sleep+0xba/0xd0 [] kmem_cache_alloc+0xaf/0xd0 [] cache_alloc_refill+0x561/0x6a0 [] kmem_cache_zalloc+0xe4/0xf0 [] copy_process+0x89/0x1280 [] do_fork+0x6b/0x1c0 [] sys_clone+0x33/0x40 [] sysenter_past_esp+0x5d/0x99 === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.20-rc5 2/4] atl1: add missing include dma-mapping.h
From: Jay Cliburn <[EMAIL PROTECTED]> Include dma-mapphing.h to provide DMA_32BIT_MASK and DMA_64BIT_MASK. Discovered by and modification suggested by Andrew Morton. Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]> --- drivers/net/atl1/atl1_main.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c index 68e6cd1..a9e02d1 100644 --- a/drivers/net/atl1/atl1_main.c +++ b/drivers/net/atl1/atl1_main.c @@ -66,6 +66,7 @@ #include #include #include +#include #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.20-rc5 1/4] atl1: unconditionally enable MSI
From: Luca Tettamanti <[EMAIL PROTECTED]>
Unconditionally enable MSI in atl1 driver. Also remove some useless
#ifdef since pci_{en,dis}able_msi() are no-op when MSI support is not
configured in.
Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]>
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1.h |1 -
drivers/net/atl1/atl1_main.c | 22 +++---
drivers/net/atl1/atl1_param.c | 13 -
3 files changed, 7 insertions(+), 29 deletions(-)
diff --git a/drivers/net/atl1/atl1.h b/drivers/net/atl1/atl1.h
index 1d13e8f..0b30e1c 100644
--- a/drivers/net/atl1/atl1.h
+++ b/drivers/net/atl1/atl1.h
@@ -281,7 +281,6 @@ struct atl1_adapter {
struct atl1_smb smb;
struct atl1_cmb cmb;
- int enable_msi;
u32 pci_state[16];
};
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index c0b1555..68e6cd1 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -1793,18 +1793,12 @@ s32 atl1_up(struct atl1_adapter *adapter)
goto err_up;
}
-#ifdef CONFIG_PCI_MSI
- if (adapter->enable_msi) {
- err = pci_enable_msi(adapter->pdev);
- if (err) {
- dev_info(>pdev->dev, "Unable to enable MSI:
%d\n", err);
- adapter->enable_msi = 0;
- }
- }
-#endif
- if (!adapter->enable_msi)
+ err = pci_enable_msi(adapter->pdev);
+ if (err) {
+ dev_info(>pdev->dev, "Unable to enable MSI: %d\n",
err);
irq_flags |= IRQF_SHARED;
-
+ }
+
err = request_irq(adapter->pdev->irq, _intr, irq_flags,
netdev->name, netdev);
if (unlikely(err))
@@ -1821,6 +1815,7 @@ s32 atl1_up(struct atl1_adapter *adapter)
free_irq(adapter->pdev->irq, netdev);
err_up:
+ pci_disable_msi(adapter->pdev);
/* free rx_buffers */
atl1_clean_rx_ring(adapter);
return err;
@@ -1836,10 +1831,7 @@ void atl1_down(struct atl1_adapter *adapter)
atl1_irq_disable(adapter);
free_irq(adapter->pdev->irq, netdev);
-#ifdef CONFIG_PCI_MSI
- if (adapter->enable_msi)
- pci_disable_msi(adapter->pdev);
-#endif
+ pci_disable_msi(adapter->pdev);
atl1_reset_hw(>hw);
adapter->cmb.cmb->int_stats = 0;
diff --git a/drivers/net/atl1/atl1_param.c b/drivers/net/atl1/atl1_param.c
index 4732f43..caa2d83 100644
--- a/drivers/net/atl1/atl1_param.c
+++ b/drivers/net/atl1/atl1_param.c
@@ -68,10 +68,6 @@ static int num_flash_vendor = 0;
module_param_array_named(flash_vendor, flash_vendor, int, _flash_vendor,
0);
MODULE_PARM_DESC(flash_vendor, "SPI flash vendor");
-int enable_msi;
-module_param(enable_msi, int, 0444);
-MODULE_PARM_DESC(enable_msi, "Enable PCI MSI");
-
#define DEFAULT_INT_MOD_CNT100 /* 200us */
#define MAX_INT_MOD_CNT65000
#define MIN_INT_MOD_CNT50
@@ -211,13 +207,4 @@ void __devinit atl1_check_options(struct atl1_adapter
*adapter)
adapter->hw.flash_vendor = (u8) (opt.def);
}
}
-
- { /* PCI MSI usage */
-
-#ifdef CONFIG_PCI_MSI
- adapter->enable_msi = enable_msi;
-#else
- adapter->enable_msi = 0;
-#endif
- }
}
Luca
--
Inquietudine sintetica
Solo, davanti all'ignoto
Tienimi stretto a te
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
On 28/01/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote: >>> On 26/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz Btw, I never received that original message, nor do I find it in the LKML archive on lkml.org. There is a mm-commits mailing list. http://vger.kernel.org/vger-lists.html#mm-commits Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
>>> On 26/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz Btw, I never received that original message, nor do I find it in the LKML archive on lkml.org. -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [Ltt-dev] [PATCH 00/09] atomic.h : standardizing atomic primitives
Andrew Morton wrote: > On Sat, 27 Jan 2007 21:09:11 +0100 > Willy Tarreau <[EMAIL PROTECTED]> wrote: > >> On Sat, Jan 27, 2007 at 12:05:12PM -0800, Andrew Morton wrote: >>> On Sat, 27 Jan 2007 13:11:16 -0500 >>> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: >>> I am currently trying crosstool by Dan Kegel, it looks promising. http://www.kegel.com/crosstool/ >>> Yeah, I spent a frustrating two days with crosstool, managed to eke a >>> number of cross-compilers out of it, but it took a *lot* of experimentation >>> with gcc, glibc and binutils versions to get combinations which actually >>> work. Good luck ;) >>> >>> There used to be someone who had a full suite, and who regularly published >>> cross-compile results, but he stopped 6-12 months ago and I forget who that >>> clever person was? >> Wasn't it buildroot from Erik Andersen ? >> >>http://buildroot.uclibc.org/ >> > > No, it was http://l4x.org/k/ It still appears to be operating, with > scary-looking results. > > Jan, is there any way in which you can help us publish a full suite of > cross-compiler binaries? Probably not. I could publish a qemu i386 image with all cross compilers though. But some are not build from source but are obtained from more or less obscure sources (m32r, sh64). Currently this CHK include/linux/utsrelease.h "2.6.20-rc6cat:include/config/kernel.release:Nosuchfileordirectory" exceeds 64 characters make[1]: *** [include/linux/utsrelease.h] Error 1 make: *** [_all] Error 2 bug, which I reported weeks ago, makes the result invalid for most archs. But as I get nearly zero feedback about the results and I've lots of other obligations currently, my motivation to work on that is pretty much nil. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc6 - suspend / resume ata_piix
On Sat, 2007-01-27 at 17:40 -0500, Jeff Garzik wrote: > > During the second resume the ATA interrupt gets disabled due to an > > unhandled interrupt. > > > > This is 100% reproducible. So I can provide as much info as needed. > > Is this a regression, or behavior that's always been present? No, that's new. Something post 2.6.19 > If its a regression, what changeset caused the problem? Hey. I just discovered that crap. I'm going to bisect tomorrow. Bed time here in good old Europe. :) tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix /sys/device/.../power/state regression
On Sat, Jan 27, 2007 at 05:38:04PM +, Pavel Machek wrote: > Change breaking that was 'introduce suspend early to fix suspend on > mac mini', by Linus, IIRC. So no, it is not easy to revert this one. But it's easy to fix it. Either drivers need suspend routines that are called without interrupts enabled, or they don't. The current situation is that the interface is broken regardless of which is the case - the situation with the patch is that the interface only stops working for drivers that need the suspend routine to be called with disabled interrupts. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc6 - suspend / resume ata_piix
Thomas Gleixner wrote: On Wed, 2007-01-24 at 18:58 -0800, Linus Torvalds wrote: It's been more than a week since -rc5, but I blame everybody (including me) being away for Linux.conf.au and then me waiting for a few days afterwards to let everybody sync up. ata_piix survives exactly one suspend resume cylce. After resuming the second time the disk is not longer usable. After the first resume a simple "emacs -nw bla.txt" takes already ~45sec to launch, but there are no kernel messages. During the second resume the ATA interrupt gets disabled due to an unhandled interrupt. This is 100% reproducible. So I can provide as much info as needed. Is this a regression, or behavior that's always been present? If its a regression, what changeset caused the problem? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
Jay Cliburn wrote: Jeff Garzik wrote: As a driver maintainer, you need to patch sets, and submit them in a timely fashion to me. Note I said patch set, not patch, in following with Rule #3 from Documentation/SubmittingPatches. Also make sure to review http://linux.yyz.us/patch-format.html Understood. Both references reviewed. Thanks. Sorry, but one last question... These two patches generated overnight by Andrew: Message-Id: <[EMAIL PROTECTED]> Subject: + git-netdev-all-atl1-pm-fix.patch added to -mm tree and Message-Id: <[EMAIL PROTECTED]> Subject: + git-netdev-all-atl1-build-fix.patch added to -mm tree Do I include these in my patch set that I submit to you, or do you apply them to netdev directly? There is no hard and fast rule. If the patch is obvious and submitted in correct form (Andrew's notifications are not in such a form), then I might go ahead and apply it. But I usually reply to the patch with "applied" if so. In general, you can answer this question yourself. Look at netdev-2.6.git#atl1 and see what's in there. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Track mlock()ed pages
Andrew Morton wrote: On Sat, 27 Jan 2007 17:19:21 -0500 Rik van Riel <[EMAIL PROTECTED]> wrote: Andrew Morton wrote: Of course it would. But how do you know it is "too expensive"? We "scan all the vmas mapping a page" as a matter of course in the page scanner - millions of times a minute. If that's "too expensive" then ouch. We can do it lazily. At mlock time, move pages onto the mlocked list, unless they are there already. Needs another page flag to determine what list the page is on (eek). On munlock, move pages to the active list. We'd need to determine whether some other vma has mlocked the page too. That's either the page_struct refcount or the vma walk. The latter is equivalent to what I'm suggesting. It doesn't have to be 100% accurate. The pages that are mapped both mlocked and non-mlocked will probably be only shared libraries. For mlock-only memory (shared memory segments?) we could add a simple check to see if the next process on the list has the page mlocked, checking only that one. As long as we get it right for the large objects, it should be fine. I'm still not sure what problem we're trying to solve here. Knowing how many mlocked pages there are in a zone doesn't sound terribly interesting and I don't recall ever wanting to know that. Being able to keep mlocked pages off the LRU altogether sounds more useful. It's all rather a tight corner case - people don't use mlock much. Just because it's not common does not mean you can just ignore it and hope Linux doesn't unexpectedly fall over. One thing that knowing the amount of mlocked data in each zone (and node) would allow us to do is spread the mlocked memory around a little better at allocation time. This could prevent some of the "I started a 6GB Oracle on my 8GB system and it immediately fell over" bugs. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Track mlock()ed pages
On Sat, 27 Jan 2007 17:19:21 -0500 Rik van Riel <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > > Of course it would. But how do you know it is "too expensive"? We "scan > > all the vmas mapping a page" as a matter of course in the page scanner - > > millions of times a minute. If that's "too expensive" then ouch. > > We can do it lazily. > > At mlock time, move pages onto the mlocked list, unless they > are there already. Needs another page flag to determine what list the page is on (eek). > On munlock, move pages to the active list. We'd need to determine whether some other vma has mlocked the page too. That's either the page_struct refcount or the vma walk. The latter is equivalent to what I'm suggesting. > For mlock-only > memory (shared memory segments?) we could add a simple check > to see if the next process on the list has the page mlocked, > checking only that one. > > While scanning the active list, move mlocked pages that are > found back onto the mlocked list. > > This lazy movement of pages will impact shared libraries, > but probably not shared memory segments. > > Does this sound workable? I'm still not sure what problem we're trying to solve here. Knowing how many mlocked pages there are in a zone doesn't sound terribly interesting and I don't recall ever wanting to know that. Being able to keep mlocked pages off the LRU altogether sounds more useful. It's all rather a tight corner case - people don't use mlock much. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Track mlock()ed pages
Andrew Morton wrote: Of course it would. But how do you know it is "too expensive"? We "scan all the vmas mapping a page" as a matter of course in the page scanner - millions of times a minute. If that's "too expensive" then ouch. We can do it lazily. At mlock time, move pages onto the mlocked list, unless they are there already. On munlock, move pages to the active list. For mlock-only memory (shared memory segments?) we could add a simple check to see if the next process on the list has the page mlocked, checking only that one. While scanning the active list, move mlocked pages that are found back onto the mlocked list. This lazy movement of pages will impact shared libraries, but probably not shared memory segments. Does this sound workable? -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
On 27/01/07, Andrew Morton <[EMAIL PROTECTED]> wrote: I have everything compiling now, mostly. The number of fixes which were needed was just extraordinary. I'm thinking about making changes... I'm so much looking forward to it. Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc6 - suspend / resume ata_piix
On Wed, 2007-01-24 at 18:58 -0800, Linus Torvalds wrote: > It's been more than a week since -rc5, but I blame everybody (including > me) being away for Linux.conf.au and then me waiting for a few days > afterwards to let everybody sync up. ata_piix survives exactly one suspend resume cylce. After resuming the second time the disk is not longer usable. After the first resume a simple "emacs -nw bla.txt" takes already ~45sec to launch, but there are no kernel messages. During the second resume the ATA interrupt gets disabled due to an unhandled interrupt. This is 100% reproducible. So I can provide as much info as needed. tglx Boot: SCSI subsystem initialized libata version 2.00 loaded. ata_piix :00:1f.2: version 2.00ac7 ata_piix :00:1f.2: MAP [ P0 P2 XX XX ] ata_piix :00:1f.2: invalid MAP value 0 ACPI: PCI Interrupt :00:1f.2[B] -> GSI 22 (level, low) -> IRQ 21 PCI: Setting latency timer of device :00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x18D0 ctl 0x18C6 bmdma 0x18B0 irq 21 ata2: SATA max UDMA/133 cmd 0x18C8 ctl 0x18C2 bmdma 0x18B8 irq 21 scsi0 : ata_piix PM: Adding info for No Bus:host0 ata1.00: ATA-7, max UDMA/133, 195371568 sectors: LBA48 NCQ (depth 0/32) ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 scsi1 : ata_piix PM: Adding info for No Bus:host1 scsi 0:0:0:0: Direct-Access ATA ST9100824AS 3.14 PQ: 0 ANSI: 5 PM: Adding info for scsi:0:0:0:0 SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 < sda5 > sda3 sd 0:0:0:0: Attached scsi disk sda 1st Suspend: ata_piix :00:1f.2: suspend ACPI: PCI interrupt for device :00:1f.2 disabled PIIX_IDE :00:1f.1: suspend PIIX_IDE :00:1f.1: LATE suspend 1st Resume: ata1.00: configured for UDMA/133 SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA 2nd Suspend as above 2nd resume: Initializing CPU#1 irq 21: nobody cared(try booting with the "irqpoll" option) ... handlers: [] (atat_interrupt+0x0/0x1cd [libata]) Disabling IRQ #21 ata1.00: qc timeout (cmd 0xe1) ata1.00: failed to spin up (err_mask=0x4) ata1.00: failed to set xfermode (err_mask=0x40) ata1.00: limiting speed to UDMA/100 ata1: failed to recover some devies, retrying in 5 secs sd 0:0:0:0: rejectimg I/O to offline device ata1.00: ATA-7, max UDMA/133, 195371568 sectors: LBA48 NCQ (depth 0/32) ata1.00: ata1: dev 0 multi count 16 sd 0:0:0:0: rejectimg I/O to offline device . - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
Jeff Garzik wrote: As a driver maintainer, you need to patch sets, and submit them in a timely fashion to me. Note I said patch set, not patch, in following with Rule #3 from Documentation/SubmittingPatches. Also make sure to review http://linux.yyz.us/patch-format.html Understood. Both references reviewed. Thanks. Sorry, but one last question... These two patches generated overnight by Andrew: Message-Id: <[EMAIL PROTECTED]> Subject: + git-netdev-all-atl1-pm-fix.patch added to -mm tree and Message-Id: <[EMAIL PROTECTED]> Subject: + git-netdev-all-atl1-build-fix.patch added to -mm tree Do I include these in my patch set that I submit to you, or do you apply them to netdev directly? Jay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 7891] New: vdso page is no longer mapped for
On Sat, 27 Jan 2007 15:01:51 -0500 "Parag Warudkar" <[EMAIL PROTECTED]> wrote: > Here is a patch that does what Andrew Morton suggested (plus some more > as explained below) . > Patch inline below and also attached in case there is whitespace > damage. Compile tested on i386 with make defconfig; make. If anyone > can test on other arches and provide feedback that'd be great. Thanks - I can test elf on powerpc. Does anyone remember how to create a.out executables? Assuming this works, I'm not surew what to do with it. Jam it into 2.6.20, I guess. The lateness*largeness product is somewhat high though. You appear to have generated this patch against an oldish kernel - there are CONFIG_COMPAT_VDSO changes in there which might muck things up. I'll see... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: 'asm' operand has impossible constraints
On Saturday 27 January 2007 16:28, S.Çağlar Onur wrote: > 27 Oca 2007 Cts tarihinde, Avi Kivity şunları yazmıştı: > > The patch looks correct, but I don't understand the gcc error message. > > Are we sure this isn't a gcc 4.2 bug? > > > > "g" appears to be equivalent to "rmi", if "i" is impossible, gcc is free > > to use "r" or "m", no? > > Accorgind to GCC devs. its not a bug > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808), on comment #5 the > problem described like; > > "g" means "r"+"i" so the register allocator in the -O0 case is selecting > "r" while in the optimize case is selecting "i" Sounds like a bug to me! After all, shouldn't the different sections of code be selecting the *same* bits ? DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
On Sat, 27 Jan 2007 22:29:40 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote: > Am 27.01.2007 17:37 schrieb Michal Piotrowski: > > On 26/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to > >> > >> > >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz > >> > > > > It's probably not mm snapshot related. This driver is just broken. > > It probably *is* mm snapshot related. This driver compiles and works > just fine in 2.6.19.2, 2.6.20-rc6 and 2.6.20-rc4-mm1. > > > drivers/isdn/gigaset/bas-gigaset.c: In function 'dump_urb': > > drivers/isdn/gigaset/bas-gigaset.c:258: error: 'struct urb' has no > > member named 'bandwidth' > > In current stable and mm releases, 'struct urb' *does* have a member > named 'bandwidth'. If some mm patch removes that member then it is > the responsibility of that patch to adapt all users of that structure > accordingly. > yup, there's a patch in Greg's USB tree which removes the bandwidth field. Mostly. I fixed it up. I have everything compiling now, mostly. The number of fixes which were needed was just extraordinary. I'm thinking about making changes... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: 'asm' operand has impossible constraints
27 Oca 2007 Cts tarihinde, Avi Kivity şunları yazmıştı: > The patch looks correct, but I don't understand the gcc error message. > Are we sure this isn't a gcc 4.2 bug? > > "g" appears to be equivalent to "rmi", if "i" is impossible, gcc is free > to use "r" or "m", no? Accorgind to GCC devs. its not a bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808), on comment #5 the problem described like; "g" means "r"+"i" so the register allocator in the -O0 case is selecting "r" while in the optimize case is selecting "i" -- S.Çağlar Onur <[EMAIL PROTECTED]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! pgpFqCCG4LPCh.pgp Description: PGP signature
Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
Am 27.01.2007 17:37 schrieb Michal Piotrowski: > On 26/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to >> >> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz >> > > It's probably not mm snapshot related. This driver is just broken. It probably *is* mm snapshot related. This driver compiles and works just fine in 2.6.19.2, 2.6.20-rc6 and 2.6.20-rc4-mm1. > drivers/isdn/gigaset/bas-gigaset.c: In function 'dump_urb': > drivers/isdn/gigaset/bas-gigaset.c:258: error: 'struct urb' has no > member named 'bandwidth' In current stable and mm releases, 'struct urb' *does* have a member named 'bandwidth'. If some mm patch removes that member then it is the responsibility of that patch to adapt all users of that structure accordingly. HTH Tilman -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
Jay Cliburn wrote: Jeff, shall I add this to the larger patch I'm working on for submittal later this weekend, or do you just add it directly to netdev? (I prefer to do the former if it's okay with you.) As a driver maintainer, you need to patch sets, and submit them in a timely fashion to me. Note I said patch set, not patch, in following with Rule #3 from Documentation/SubmittingPatches. Also make sure to review http://linux.yyz.us/patch-format.html Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ISDN: Fix typo "CONFIG_HISAX_QUADRO" -> "CONFIG_HISAX_SCT_QUADRO".
Replace misspelled CONFIG_HISAX_QUADRO with CONFIG_HISAX_SCT_QUADRO.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/drivers/isdn/hisax/config.c b/drivers/isdn/hisax/config.c
index 17ec0b7..29e98f7 100644
--- a/drivers/isdn/hisax/config.c
+++ b/drivers/isdn/hisax/config.c
@@ -1881,7 +1881,7 @@ static struct pci_device_id hisax_pci_tbl[] __devinitdata
= {
{PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_DJINN_ITOO, PCI_ANY_ID,
PCI_ANY_ID},
{PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_OLITEC, PCI_ANY_ID,
PCI_ANY_ID},
#endif
-#ifdef CONFIG_HISAX_QUADRO
+#ifdef CONFIG_HISAX_SCT_QUADRO
{PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9050, PCI_ANY_ID,
PCI_ANY_ID},
#endif
#ifdef CONFIG_HISAX_NICCY
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://www.fsdev.dreamhosters.com/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Nozmi status ?
On Sat, 27 Jan 2007, Lee Revell wrote: > > What is the status of the HSDPA driver after 2.6.19.1 ? Is it part of > > the kernel tree or not yet ? If not is there any version of ther > > nozomi pack which is gonna compile under ker > 2.6.18 (the original > > one is not compiling anymore after 2.6.18). > It's up to the vendor to fix the driver to work with newer kernels > and/or submit the driver for inclusion in the kernel. Do you know > whether they've done that? There is a nozomi HSDPA driver in recent -mm kernels which compiles (gregkh-driver-nozomi.patch). -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ISDN: Rename some debugging macros to not resemble CONFIG options.
Rename some of the debugging macros for ISDN AVM so that they don't
resemble kernel config settings, as they're primarily for author
debugging instead.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
Replace the "CONFIG_" prefix with an "AVM_" prefix so that the macro
name is still relatively meaningful.
drivers/isdn/hardware/avm/b1dma.c | 14 +++---
drivers/isdn/hardware/avm/c4.c| 16
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/isdn/hardware/avm/b1dma.c
b/drivers/isdn/hardware/avm/b1dma.c
index ddd47cd..1e2d38e 100644
--- a/drivers/isdn/hardware/avm/b1dma.c
+++ b/drivers/isdn/hardware/avm/b1dma.c
@@ -29,7 +29,7 @@
static char *revision = "$Revision: 1.1.2.3 $";
-#undef CONFIG_B1DMA_DEBUG
+#undef AVM_B1DMA_DEBUG
/* - */
@@ -391,16 +391,16 @@ static void b1dma_dispatch_tx(avmcard *card)
_put_slice(, skb->data, len);
}
txlen = (u8 *)p - (u8 *)dma->sendbuf.dmabuf;
-#ifdef CONFIG_B1DMA_DEBUG
+#ifdef AVM_B1DMA_DEBUG
printk(KERN_DEBUG "tx: put msg len=%d\n", txlen);
#endif
} else {
txlen = skb->len-2;
-#ifdef CONFIG_B1DMA_POLLDEBUG
+#ifdef AVM_B1DMA_POLLDEBUG
if (skb->data[2] == SEND_POLLACK)
printk(KERN_INFO "%s: send ack\n", card->name);
#endif
-#ifdef CONFIG_B1DMA_DEBUG
+#ifdef AVM_B1DMA_DEBUG
printk(KERN_DEBUG "tx: put 0x%x len=%d\n",
skb->data[2], txlen);
#endif
@@ -450,7 +450,7 @@ static void b1dma_handle_rx(avmcard *card)
u32 ApplId, MsgLen, DataB3Len, NCCI, WindowSize;
u8 b1cmd = _get_byte();
-#ifdef CONFIG_B1DMA_DEBUG
+#ifdef AVM_B1DMA_DEBUG
printk(KERN_DEBUG "rx: 0x%x %lu\n", b1cmd, (unsigned long)dma->recvlen);
#endif
@@ -515,7 +515,7 @@ static void b1dma_handle_rx(avmcard *card)
break;
case RECEIVE_START:
-#ifdef CONFIG_B1DMA_POLLDEBUG
+#ifdef AVM_B1DMA_POLLDEBUG
printk(KERN_INFO "%s: receive poll\n", card->name);
#endif
if (!suppress_pollack)
@@ -601,7 +601,7 @@ static void b1dma_handle_interrupt(avmcard *card)
rxlen = (dma->recvlen + 3) & ~3;
b1dma_writel(card, dma->recvbuf.dmaaddr+4,
AMCC_RXPTR);
b1dma_writel(card, rxlen, AMCC_RXLEN);
-#ifdef CONFIG_B1DMA_DEBUG
+#ifdef AVM_B1DMA_DEBUG
} else {
printk(KERN_ERR "%s: rx not complete (%d).\n",
card->name, rxlen);
diff --git a/drivers/isdn/hardware/avm/c4.c b/drivers/isdn/hardware/avm/c4.c
index 2a3eb38..6f5efa8 100644
--- a/drivers/isdn/hardware/avm/c4.c
+++ b/drivers/isdn/hardware/avm/c4.c
@@ -28,8 +28,8 @@
#include
#include "avmcard.h"
-#undef CONFIG_C4_DEBUG
-#undef CONFIG_C4_POLLDEBUG
+#undef AVM_C4_DEBUG
+#undef AVM_C4_POLLDEBUG
/* - */
@@ -420,7 +420,7 @@ static void c4_dispatch_tx(avmcard *card)
skb = skb_dequeue(>send_queue);
if (!skb) {
-#ifdef CONFIG_C4_DEBUG
+#ifdef AVM_C4_DEBUG
printk(KERN_DEBUG "%s: tx underrun\n", card->name);
#endif
return;
@@ -444,16 +444,16 @@ static void c4_dispatch_tx(avmcard *card)
_put_slice(, skb->data, len);
}
txlen = (u8 *)p - (u8 *)dma->sendbuf.dmabuf;
-#ifdef CONFIG_C4_DEBUG
+#ifdef AVM_C4_DEBUG
printk(KERN_DEBUG "%s: tx put msg len=%d\n", card->name, txlen);
#endif
} else {
txlen = skb->len-2;
-#ifdef CONFIG_C4_POLLDEBUG
+#ifdef AVM_C4_POLLDEBUG
if (skb->data[2] == SEND_POLLACK)
printk(KERN_INFO "%s: ack to c4\n", card->name);
#endif
-#ifdef CONFIG_C4_DEBUG
+#ifdef AVM_C4_DEBUG
printk(KERN_DEBUG "%s: tx put 0x%x len=%d\n",
card->name, skb->data[2], txlen);
#endif
@@ -508,7 +508,7 @@ static void c4_handle_rx(avmcard *card)
u32 cidx;
-#ifdef CONFIG_C4_DEBUG
+#ifdef AVM_C4_DEBUG
printk(KERN_DEBUG "%s: rx 0x%x len=%lu\n", card->name,
b1cmd, (unsigned long)dma->recvlen);
#endif
@@ -586,7 +586,7 @@ static void c4_handle_rx(avmcard *card)
break;
case RECEIVE_START:
-#ifdef CONFIG_C4_POLLDEBUG
+#ifdef AVM_C4_POLLDEBUG
printk(KERN_INFO "%s: poll from c4\n", card->name);
#endif
if (!suppress_pollack)
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://www.fsdev.dreamhosters.com/wiki/index.php?title=Main_Page
-
To
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
Luca Tettamanti wrote:
[snip]
Anyway...
Unconditionally enable MSI in atl1 driver. Also remove some useless
#ifdef since pci_{en,dis}able_msi() are no-op when MSI support is not
configured in.
Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]>
Acked-by: Jay Cliburn <[EMAIL PROTECTED]>
I tested this patch today. Works fine on my Asus M2V mainboard (Via
K8T890).
Here are the eth0 entries in /proc/interrupts before and after the patch.
BEFORE:36: 93 322091 IO-APIC-fasteoi eth0
AFTER: 2298: 85 7289 PCI-MSI-edge eth0
Jeff, shall I add this to the larger patch I'm working on for submittal
later this weekend, or do you just add it directly to netdev? (I prefer
to do the former if it's okay with you.)
Jay
---
Patch against current netdev tree.
drivers/net/atl1/atl1.h |1 -
drivers/net/atl1/atl1_main.c | 22 +++---
drivers/net/atl1/atl1_param.c | 13 -
3 files changed, 7 insertions(+), 29 deletions(-)
diff --git a/drivers/net/atl1/atl1.h b/drivers/net/atl1/atl1.h
index 1d13e8f..0b30e1c 100644
--- a/drivers/net/atl1/atl1.h
+++ b/drivers/net/atl1/atl1.h
@@ -281,7 +281,6 @@ struct atl1_adapter {
struct atl1_smb smb;
struct atl1_cmb cmb;
- int enable_msi;
u32 pci_state[16];
};
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index c0b1555..68e6cd1 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -1793,18 +1793,12 @@ s32 atl1_up(struct atl1_adapter *adapter)
goto err_up;
}
-#ifdef CONFIG_PCI_MSI
- if (adapter->enable_msi) {
- err = pci_enable_msi(adapter->pdev);
- if (err) {
- dev_info(>pdev->dev, "Unable to enable MSI:
%d\n", err);
- adapter->enable_msi = 0;
- }
- }
-#endif
- if (!adapter->enable_msi)
+ err = pci_enable_msi(adapter->pdev);
+ if (err) {
+ dev_info(>pdev->dev, "Unable to enable MSI: %d\n",
err);
irq_flags |= IRQF_SHARED;
-
+ }
+
err = request_irq(adapter->pdev->irq, _intr, irq_flags,
netdev->name, netdev);
if (unlikely(err))
@@ -1821,6 +1815,7 @@ s32 atl1_up(struct atl1_adapter *adapter)
free_irq(adapter->pdev->irq, netdev);
err_up:
+ pci_disable_msi(adapter->pdev);
/* free rx_buffers */
atl1_clean_rx_ring(adapter);
return err;
@@ -1836,10 +1831,7 @@ void atl1_down(struct atl1_adapter *adapter)
atl1_irq_disable(adapter);
free_irq(adapter->pdev->irq, netdev);
-#ifdef CONFIG_PCI_MSI
- if (adapter->enable_msi)
- pci_disable_msi(adapter->pdev);
-#endif
+ pci_disable_msi(adapter->pdev);
atl1_reset_hw(>hw);
adapter->cmb.cmb->int_stats = 0;
diff --git a/drivers/net/atl1/atl1_param.c b/drivers/net/atl1/atl1_param.c
index 4732f43..caa2d83 100644
--- a/drivers/net/atl1/atl1_param.c
+++ b/drivers/net/atl1/atl1_param.c
@@ -68,10 +68,6 @@ static int num_flash_vendor = 0;
module_param_array_named(flash_vendor, flash_vendor, int, _flash_vendor,
0);
MODULE_PARM_DESC(flash_vendor, "SPI flash vendor");
-int enable_msi;
-module_param(enable_msi, int, 0444);
-MODULE_PARM_DESC(enable_msi, "Enable PCI MSI");
-
#define DEFAULT_INT_MOD_CNT100 /* 200us */
#define MAX_INT_MOD_CNT65000
#define MIN_INT_MOD_CNT50
@@ -211,13 +207,4 @@ void __devinit atl1_check_options(struct atl1_adapter
*adapter)
adapter->hw.flash_vendor = (u8) (opt.def);
}
}
-
- { /* PCI MSI usage */
-
-#ifdef CONFIG_PCI_MSI
- adapter->enable_msi = enable_msi;
-#else
- adapter->enable_msi = 0;
-#endif
- }
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] take 3: mmc_spi with SPI_TX_1 2.6.20-rc6
> Date: Sat, 27 Jan 2007 21:19:29 +0100 > From: Hans-Peter Nilsson <[EMAIL PROTECTED]> > > From: David Brownell <[EMAIL PROTECTED]> > > Date: Fri, 26 Jan 2007 20:21:54 -0800 > > (I can update your patch #4, etc, to match.) > Or I could, and test it to boot. :) Lightly tested: mounted, deleted a file, verified contents elsewhere (that the directory entry was gone). (Previous authors: Mike Lavender, David Brownell, missing explicit signoff) Signed-off-by: Hans-Peter Nilsson <[EMAIL PROTECTED]> diff -uprN a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig --- a/drivers/mmc/Kconfig 2007-01-13 18:59:19.0 +0100 +++ b/drivers/mmc/Kconfig 2007-01-14 12:52:17.0 +0100 @@ -125,4 +125,15 @@ config MMC_TIFM_SD To compile this driver as a module, choose M here: the module will be called tifm_sd. +config MMC_SPI + tristate "MMC/SD over SPI" + depends on MMC && SPI && EXPERIMENTAL + help + Some systems accss MMC/SD cards using the SPI protocol instead of + using an MMC/SD controller. The disadvantage of using SPI is that + it's often not as fast; its compensating advantage is that SPI is + available on many systems without MMC/SD controllers. + + If unsure, or if your system has no SPI controller driver, say N. + endmenu diff -uprN a/drivers/mmc/Makefile b/drivers/mmc/Makefile --- a/drivers/mmc/Makefile 2007-01-13 18:59:19.0 +0100 +++ b/drivers/mmc/Makefile 2007-01-14 12:54:06.0 +0100 @@ -24,6 +24,7 @@ obj-$(CONFIG_MMC_AU1X)+= au1xmmc.o obj-$(CONFIG_MMC_OMAP) += omap.o obj-$(CONFIG_MMC_AT91RM9200) += at91_mci.o obj-$(CONFIG_MMC_TIFM_SD) += tifm_sd.o +obj-$(CONFIG_MMC_SPI) += mmc_spi.o mmc_core-y := mmc.o mmc_sysfs.o sdio.o mmc_core-$(CONFIG_BLOCK) += mmc_queue.o --- a/drivers/mmc/mmc_spi.c 1970-01-01 01:00:00.0 +0100 +++ b/drivers/mmc/mmc_spi.c 2007-01-27 21:39:25.160981313 +0100 @@ -0,0 +1,1499 @@ +/* + * mmc_spi.c - Access an SD/MMC card using the SPI bus + * + * (C) Copyright 2005, Intec Automation, + * Mike Lavender ([EMAIL PROTECTED]) + * (C) Copyright 2006, David Brownell + * (C) Copyright 2007, Axis Communications, + * Hans-Peter Nilsson ([EMAIL PROTECTED]) + * + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include + + +/* NOTES: + * + * - For now, we won't try to interoperate with a real mmc/sd/sdio + * controller. The main reason for such configs would be mmc-format + * cards which (like dataflash) don't support that "other" protocol. + * SPI mode is a bit slower than non-parallel versions of MMC. + * + * - Likewise we don't try to detect dataflash cards, which would + * imply switching to a different driver. Not many folk folk use + * both dataflash cards and MMC/SD cards, and Linux doesn't have + * an "MMC/SD interface" abstraction for coupling to drivers. + * + * - This version gets part way through enumeration of MMC cards. + * + * - Protocol details, including timings, need to be audited + * + * - A "use CRCs" option would probably be useful. + */ + + +/* + * Local defines + */ + +// MOVE TO ? +#define SPI_MMC_COMMAND0x40/* mask into mmc command */ + +/* class 0 */ +#define SPI_MMC_READ_OCR 58 /* R3, SPI-only */ +#define SPI_MMC_CRC_ON_OFF 59 /* SPI-only */ + +/* R1 response status to almost all commands */ +#define SPI_MMC_R1_IDLE0x01 +#define SPI_MMC_R1_ERASE_RESET 0x02 +#define SPI_MMC_R1_ILLEGAL_COMMAND 0x04 +#define SPI_MMC_R1_COM_CRC 0x08 +#define SPI_MMC_R1_ERASE_SEQ 0x10 +#define SPI_MMC_R1_ADDRESS 0x20 +#define SPI_MMC_R1_PARAMETER 0x40 + +/* R2 response to CMD13 (SEND_STATUS) is an R1 plus a high byte */ +#define SPI_MMC_R2_CARD_LOCKED 0x01 +#define SPI_MMC_R2_WP_ERASE_SKIP 0x02 +#define SPI_MMC_R2_ERROR 0x04 +#define SPI_MMC_R2_CC_ERROR0x08 +#define SPI_MMC_R2_CARD_ECC_ERROR 0x10 +#define SPI_MMC_R2_WP_VIOLATION0x20 +#define SPI_MMC_R2_ERASE_PARAM 0x40 +#define
Re: Raid 10 question/problem [ot]
On Jan 27 2007 10:42, Marc Perkel wrote: >> > >> >I'm using Fedora Core 6. /dev/md0 and /dev/md1, buth of which are raid >> >1 arrays survive the reboot. But when I make a raid 0 out of those two >> >raid arrays that's what is vanishing. >> >> That's interesting. I am using Aurora Corona [FC6+RHide], and all but >> md0 vanishes. (Reason for that is that udev does not create the nodes >> md1-md31 on boot, so mdadm cannot assemble the arrays.) > >What do you have to do to get UDEV to create /dev/md2? Is there a config >file for that? That's the big question. On openSUSE 10.2, all the md devices get created automatically. I suppose that happens as part of udev processing all the queued kernel events at bootup. On default FC6 install (i.e. without any raid), only /dev/md0 is present (like in Aurora). That alone, and that you got md1 there, and I don't, is strange. I think I found it. udev does not do md at all, for some reason. This line in /etc/rc.d/rc.sysinit is quite "offending": [ -x /sbin/nash ] && echo "raidautorun /dev/md0" | nash --quiet Starting a init=/bin/bash prompt and doing "/usr/sbin/udevmonitor &" there reveals: bash-3.1# echo raidautorun /dev/md0 | /sbin/nash --quiet UEVENT[1169934663.372139] add@/block/md0 bash-3.1# echo raidautorun /dev/md1 | /sbin/nash --quiet UEVENT[1169934667.601027] add@/block/md1 No sign of md1. (Wtf here!) I can see why it's broken, but to nash every md device sounds like the worst solution around. I'd say the Fedora boot process is severely broken wrt. md. Well, what's your rc.sysinit looking like, since you seem to be having a md1 floating around? -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc6 - sky2 resume breakage
On Wed, 2007-01-24 at 18:58 -0800, Linus Torvalds wrote: > It's been more than a week since -rc5, but I blame everybody (including > me) being away for Linux.conf.au and then me waiting for a few days > afterwards to let everybody sync up. Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd (sky2: power management/MSI workaround) makes the problem go away. With the commit it breaks sky2 resume on my laptop: 1. request_irq in early resume is triggering: BUG: sleeping function called from invalid context at /home/tglx/work/kernel/vanilla/linux-2.6/mm/slab.c:3034 This is easy resolvable by moving the request_irq into the normal resume path. There is no need to have this in early resume. 2. The network device is unusable after resume. The only way to resurect it is: rmmod/insmod. The reason is, that the driver grabs the normal PCI irq on resume, but the pci express resume routes it away. All we get is an unhandled spurious interrupt on the irq line which was used by the net device before suspend: irq 219, desc: c045bb80, depth: 0, count: 9607, unhandled: 0 ->handle_irq(): c0155c20, handle_bad_irq+0x0/0x1f0 ->chip(): c0418920, no_irq_chip+0x0/0x40 ->action(): IRQ_DISABLED set unexpected IRQ trap at vector db tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
O_NONBLOCK setting "leak" outside of a process??
Hi,
I am currently on Linux 2.6.18, x86_64.
I came across strange behavior while working on one
of busybox applets. I narrowed it down to these two
trivial testcases:
#include
#include
int main() {
fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
return 0;
}
#include
#include
int main() {
fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) & ~O_NONBLOCK);
return 0;
}
If I run "nonblock" in Midnight Commander in KDE's Konsole,
screen redraw starts to work ~5 times slower. For example,
Ctrl-O ("show/hide panels" in MC) takes ~0.5 sec to redraw.
This persists after the program exist (which it
does immediately as you see).
Running "block" reverts things to normal.
I mean: how can O_NONBLOCK _issued in a process which
already exited_ have any effect whatsoever on MC or Konsole?
They can't even know that it did it, right?
Either I do not know something subtle about Unix or some sort
of bug is at work.
Any advice?
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Dynamic kernel command-line - fixups
Remove in-source externs, linux/init.h is included in all cases.
This is a fixups for "Dynamic kernel command-line" patch.
It includes the ia64 fixup already added.
It also includes some uml __init fixups so that we can __initdata also its
command_line.
[[[ I will resubmit it to next mm version as you requested,
I don't mean to bother you. if you find this simple
enough you have an option to include this. ]]]
Signed-off-by: Alon Bar-Lev <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.20-rc4-mm1.dyn-cmdline/arch/ia64/kernel/efi.c
linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/ia64/kernel/efi.c
--- linux-2.6.20-rc4-mm1.dyn-cmdline/arch/ia64/kernel/efi.c 2007-01-22
23:32:30.0 +0200
+++ linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/ia64/kernel/efi.c
2007-01-27 21:56:07.0 +0200
@@ -413,7 +413,6 @@ efi_init (void)
efi_char16_t *c16;
u64 efi_desc_size;
char *cp, vendor[100] = "unknown";
- extern char __initdata boot_command_line[];
int i;
/* it's too early to be able to use the standard kernel command line
support... */
diff -urNp linux-2.6.20-rc4-mm1.dyn-cmdline/arch/ia64/kernel/sal.c
linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/ia64/kernel/sal.c
--- linux-2.6.20-rc4-mm1.dyn-cmdline/arch/ia64/kernel/sal.c 2007-01-22
23:32:30.0 +0200
+++ linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/ia64/kernel/sal.c
2007-01-27 21:57:07.0 +0200
@@ -194,7 +194,6 @@ static void __init
chk_nointroute_opt(void)
{
char *cp;
- extern char __initdata boot_command_line[];
for (cp = boot_command_line; *cp; ) {
if (memcmp(cp, "nointroute", 10) == 0) {
diff -urNp linux-2.6.20-rc4-mm1.dyn-cmdline/arch/parisc/mm/init.c
linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/parisc/mm/init.c
--- linux-2.6.20-rc4-mm1.dyn-cmdline/arch/parisc/mm/init.c 2007-01-22
23:32:30.0 +0200
+++ linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/parisc/mm/init.c
2007-01-27 22:06:51.0 +0200
@@ -77,7 +77,6 @@ static void __init mem_limit_func(void)
{
char *cp, *end;
unsigned long limit;
- extern char __initdata boot_command_line[];
/* We need this before __setup() functions are called */
diff -urNp linux-2.6.20-rc4-mm1.dyn-cmdline/arch/um/include/user_util.h
linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/um/include/user_util.h
--- linux-2.6.20-rc4-mm1.dyn-cmdline/arch/um/include/user_util.h
2007-01-22 23:32:31.0 +0200
+++ linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/um/include/user_util.h
2007-01-27 21:57:41.0 +0200
@@ -38,8 +38,6 @@ extern unsigned long long highmem;
extern char host_info[];
-extern char __initdata boot_command_line[];
-
extern unsigned long _stext, _etext, _sdata, _edata, __bss_start, _end;
extern unsigned long _unprotected_end;
extern unsigned long brk_start;
diff -urNp linux-2.6.20-rc4-mm1.dyn-cmdline/arch/um/kernel/um_arch.c
linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/um/kernel/um_arch.c
--- linux-2.6.20-rc4-mm1.dyn-cmdline/arch/um/kernel/um_arch.c 2007-01-22
23:32:31.0 +0200
+++ linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/um/kernel/um_arch.c
2007-01-27 22:28:48.0 +0200
@@ -44,9 +44,9 @@
#define DEFAULT_COMMAND_LINE "root=98:0"
/* Changed in linux_main and setup_arch, which run before SMP is started */
-static char command_line[COMMAND_LINE_SIZE] = { 0 };
+static char __initdata command_line[COMMAND_LINE_SIZE] = { 0 };
-static void add_arg(char *arg)
+static void __init add_arg(char *arg)
{
if (strlen(command_line) + strlen(arg) + 1 > COMMAND_LINE_SIZE) {
printf("add_arg: Too many command line arguments!\n");
@@ -331,7 +331,7 @@ EXPORT_SYMBOL(end_iomem);
extern char __binary_start;
-int linux_main(int argc, char **argv)
+int __init linux_main(int argc, char **argv)
{
unsigned long avail, diff;
unsigned long virtmem_size, max_physmem;
diff -urNp linux-2.6.20-rc4-mm1.dyn-cmdline/arch/x86_64/kernel/head64.c
linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/x86_64/kernel/head64.c
--- linux-2.6.20-rc4-mm1.dyn-cmdline/arch/x86_64/kernel/head64.c
2007-01-22 23:32:31.0 +0200
+++ linux-2.6.20-rc4-mm1.dyn-cmdline.fixups/arch/x86_64/kernel/head64.c
2007-01-27 21:57:26.0 +0200
@@ -34,8 +34,6 @@ static void __init clear_bss(void)
#define OLD_CL_BASE_ADDR0x9
#define OLD_CL_OFFSET 0x90022
-extern char __initdata boot_command_line[];
-
static void __init copy_bootdata(char *real_mode_data)
{
int new_data;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc6 - supend lockdep warning
On Wed, 2007-01-24 at 18:58 -0800, Linus Torvalds wrote:
> It's been more than a week since -rc5, but I blame everybody (including
> me) being away for Linux.conf.au and then me waiting for a few days
> afterwards to let everybody sync up.
2.6.20-rc6-git (today) on a dual core laptop:
PM: Preparing system for mem sleep
Disabling non-boot CPUs ...
===
[ INFO: possible circular locking dependency detected ]
2.6.20-rc6 #3
---
pm-suspend/3601 is trying to acquire lock:
(cpu_bitmask_lock){--..}, at: [] mutex_lock+0x1c/0x1f
but task is already holding lock:
(workqueue_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (workqueue_mutex){--..}:
[] __lock_acquire+0x8dd/0xa04
[] lock_acquire+0x56/0x6f
[] __mutex_lock_slowpath+0xe5/0x274
[] mutex_lock+0x1c/0x1f
[] __create_workqueue+0x61/0x136
[] cpufreq_governor_dbs+0xa1/0x30e [cpufreq_ondemand]
[] __cpufreq_governor+0x9e/0xd2
[] __cpufreq_set_policy+0x187/0x209
[] store_scaling_governor+0x164/0x1b1
[] store+0x37/0x48
[] sysfs_write_file+0xb3/0xdb
[] vfs_write+0xaf/0x163
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5d/0x99
[] 0x
-> #2 (dbs_mutex){--..}:
[] __lock_acquire+0x8dd/0xa04
[] lock_acquire+0x56/0x6f
[] __mutex_lock_slowpath+0xe5/0x274
[] mutex_lock+0x1c/0x1f
[] cpufreq_governor_dbs+0x85/0x30e [cpufreq_ondemand]
[] __cpufreq_governor+0x9e/0xd2
[] __cpufreq_set_policy+0x187/0x209
[] store_scaling_governor+0x164/0x1b1
[] store+0x37/0x48
[] sysfs_write_file+0xb3/0xdb
[] vfs_write+0xaf/0x163
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5d/0x99
[] 0x
-> #1 (>lock){--..}:
[] __lock_acquire+0x8dd/0xa04
[] lock_acquire+0x56/0x6f
[] __mutex_lock_slowpath+0xe5/0x274
[] mutex_lock+0x1c/0x1f
[] cpufreq_set_policy+0x29/0x79
[] cpufreq_add_dev+0x342/0x48a
[] sysdev_driver_register+0x5f/0xa9
[] cpufreq_register_driver+0xac/0x175
[] centrino_init+0x9b/0xa2
[] init+0x11b/0x2c8
[] kernel_thread_helper+0x7/0x10
[] 0x
-> #0 (cpu_bitmask_lock){--..}:
[] __lock_acquire+0x7de/0xa04
[] lock_acquire+0x56/0x6f
[] __mutex_lock_slowpath+0xe5/0x274
[] mutex_lock+0x1c/0x1f
[] lock_cpu_hotplug+0x6c/0x78
[] cpufreq_driver_target+0x28/0x5e
[] cpufreq_cpu_callback+0x42/0x52
[] notifier_call_chain+0x20/0x31
[] raw_notifier_call_chain+0x8/0xa
[] _cpu_down+0x47/0x1fb
[] disable_nonboot_cpus+0x7b/0x100
[] enter_state+0x91/0x1bb
[] state_store+0x86/0x9c
[] subsys_attr_store+0x20/0x25
[] sysfs_write_file+0xb3/0xdb
[] vfs_write+0xaf/0x163
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5d/0x99
[] 0x
other info that might help us debug this:
4 locks held by pm-suspend/3601:
#0: (pm_mutex){--..}, at: [] enter_state+0x40/0x1bb
#1: (cpu_add_remove_lock){--..}, at: [] mutex_lock+0x1c/0x1f
#2: (cache_chain_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
#3: (workqueue_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
stack backtrace:
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] print_circular_bug_tail+0x5f/0x68
[] __lock_acquire+0x7de/0xa04
[] lock_acquire+0x56/0x6f
[] __mutex_lock_slowpath+0xe5/0x274
[] mutex_lock+0x1c/0x1f
[] lock_cpu_hotplug+0x6c/0x78
[] cpufreq_driver_target+0x28/0x5e
[] cpufreq_cpu_callback+0x42/0x52
[] notifier_call_chain+0x20/0x31
[] raw_notifier_call_chain+0x8/0xa
[] _cpu_down+0x47/0x1fb
[] disable_nonboot_cpus+0x7b/0x100
[] enter_state+0x91/0x1bb
[] state_store+0x86/0x9c
[] subsys_attr_store+0x20/0x25
[] sysfs_write_file+0xb3/0xdb
[] vfs_write+0xaf/0x163
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5d/0x99
===
Breaking affinity for irq 1
Breaking affinity for irq 12
Breaking affinity for irq 21
Breaking affinity for irq 22
Breaking affinity for irq 219
CPU 1 is now offline
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
On Sat, Jan 27, 2007 at 04:05:19PM +0100, Michal Piotrowski wrote:
>
> git-cryptodev.patch removes CRYPTO_TFM_MODE_CBC but it is still defined as
> ECRYPTFS_DEFAULT_CHAINING_MODE
> in fs/ecryptfs/ecryptfs_kernel.h
>
> What should be a new ECRYPTFS_DEFAULT_CHAINING_MODE ?
It should simply be removed.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
On Sat, Jan 27, 2007 at 09:49:21AM +1100, Herbert Xu wrote:
>
> That macro has been obsolete for ages. I wonder why ecryptfs is still
> using it. Oh well I'll restore it for now.
What I ended up doing is adding the following patch to cryptodev-2.6.
So if you pull again it should be there now.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 7196f50..a86a55c 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -828,9 +828,7 @@ int ecryptfs_init_crypt_ctx(struct ecryptfs_crypt_stat
*crypt_stat)
mutex_unlock(_stat->cs_tfm_mutex);
goto out;
}
- crypto_blkcipher_set_flags(crypt_stat->tfm,
- (ECRYPTFS_DEFAULT_CHAINING_MODE
- | CRYPTO_TFM_REQ_WEAK_KEY));
+ crypto_blkcipher_set_flags(crypt_stat->tfm, CRYPTO_TFM_REQ_WEAK_KEY);
mutex_unlock(_stat->cs_tfm_mutex);
rc = 0;
out:
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index afb64bd..0f89710 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -176,7 +176,6 @@ ecryptfs_get_key_payload_data(struct key *key)
#define ECRYPTFS_FILE_SIZE_BYTES 8
#define ECRYPTFS_DEFAULT_CIPHER "aes"
#define ECRYPTFS_DEFAULT_KEY_BYTES 16
-#define ECRYPTFS_DEFAULT_CHAINING_MODE CRYPTO_TFM_MODE_CBC
#define ECRYPTFS_DEFAULT_HASH "md5"
#define ECRYPTFS_TAG_3_PACKET_TYPE 0x8C
#define ECRYPTFS_TAG_11_PACKET_TYPE 0xED
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ltt-dev] [PATCH 00/09] atomic.h : standardizing atomic primitives
> Wasn't it buildroot from Erik Andersen ? > >http://buildroot.uclibc.org/ > No, it was http://l4x.org/k/ It still appears to be operating, with scary-looking results. Jan, is there any way in which you can help us publish a full suite of cross-compiler binaries? That's going to be tricky, even if they're statically linked, what architecture do you want them for, etc? Plus some things seem to just refuse to statically link now (anything with resolver code, though maybe gcc doesn't care). If we can get the crosstool configs to build all that stuff ourselves, for any platform, would be more flexible, IMHO. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ltt-dev] [PATCH 00/09] atomic.h : standardizing atomic primitives
On Sat, 27 Jan 2007 21:09:11 +0100 Willy Tarreau <[EMAIL PROTECTED]> wrote: > On Sat, Jan 27, 2007 at 12:05:12PM -0800, Andrew Morton wrote: > > On Sat, 27 Jan 2007 13:11:16 -0500 > > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > > > > I am currently trying crosstool by Dan Kegel, it looks promising. > > > http://www.kegel.com/crosstool/ > > > > Yeah, I spent a frustrating two days with crosstool, managed to eke a > > number of cross-compilers out of it, but it took a *lot* of experimentation > > with gcc, glibc and binutils versions to get combinations which actually > > work. Good luck ;) > > > > There used to be someone who had a full suite, and who regularly published > > cross-compile results, but he stopped 6-12 months ago and I forget who that > > clever person was? > > Wasn't it buildroot from Erik Andersen ? > >http://buildroot.uclibc.org/ > No, it was http://l4x.org/k/ It still appears to be operating, with scary-looking results. Jan, is there any way in which you can help us publish a full suite of cross-compiler binaries? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] take 2: (was-kind-of: 3/5 SPI tx_default) 2.6.20-rc6
> Date: Sat, 27 Jan 2007 21:19:29 +0100 > From: Hans-Peter Nilsson <[EMAIL PROTECTED]> > Add SPI_LSB_FIRST (still supported by spi_bitbang, I presume :) Never mind, I just noticed that I can't read. brgds, H-P - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] take 2: (was-kind-of: 3/5 SPI tx_default) 2.6.20-rc6
> From: David Brownell <[EMAIL PROTECTED]> > Date: Fri, 26 Jan 2007 20:21:54 -0800 > In fact, how about this one instead? It uses a bit in spi->mode > since that's pretty easy to test. And while it doesn't get rid > of the multiple conditionals when the tx buffer is null, it does > let the other values be constants (0, ~0) that compilers like. I'm fine, except the typo. > (I can update your patch #4, etc, to match.) Or I could, and test it to boot. :) > +#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_TX_1) Add SPI_LSB_FIRST (still supported by spi_bitbang, I presume :) brgds, H-P - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Nozmi status ?
On 1/27/07, Gianluca Alberici <[EMAIL PROTECTED]> wrote: Hello, What is the status of the HSDPA driver after 2.6.19.1 ? Is it part of the kernel tree or not yet ? If not is there any version of ther nozomi pack which is gonna compile under ker > 2.6.18 (the original one is not compiling anymore after 2.6.18). It's up to the vendor to fix the driver to work with newer kernels and/or submit the driver for inclusion in the kernel. Do you know whether they've done that? Right now it's impossible to even review the driver because the sources are only available as attachments to forum posts that require registration to read. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ltt-dev] [PATCH 00/09] atomic.h : standardizing atomic primitives
On Sat, Jan 27, 2007 at 12:05:12PM -0800, Andrew Morton wrote: > On Sat, 27 Jan 2007 13:11:16 -0500 > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > > I am currently trying crosstool by Dan Kegel, it looks promising. > > http://www.kegel.com/crosstool/ > > Yeah, I spent a frustrating two days with crosstool, managed to eke a > number of cross-compilers out of it, but it took a *lot* of experimentation > with gcc, glibc and binutils versions to get combinations which actually > work. Good luck ;) > > There used to be someone who had a full suite, and who regularly published > cross-compile results, but he stopped 6-12 months ago and I forget who that > clever person was? Wasn't it buildroot from Erik Andersen ? http://buildroot.uclibc.org/ Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] PM: fast power off - core
My apologies, I cc'd the wrong list the first time around.
- Armin
---
Fastpoweroff allows a user to power down the system without using rc kill
scripts. This is used in the advent of a battery operated device about to lose
power. The user interface is vis sysfs /sys/power/fastpoweroff. A simple cat of
the fastpoweroff will list any registered profiles. To invoke
the profile sequence, echo {profile name} > /sys/power/fastpoweroff.
This is the core code for fastpoweroff profile support, it includes a
register/unregister and default profile callbacks.
Signed-off-by: Armin Kuster <[EMAIL PROTECTED]>
---
fs/super.c|6 +
kernel/power/Kconfig |2
kernel/power/Makefile |2
kernel/power/fastoff/Kconfig | 13 +++
kernel/power/fastoff/Makefile |8 ++
kernel/power/fastoff/fpo.c| 155 ++
kernel/power/fastoff/fpo.h| 27 +++
7 files changed, 213 insertions(+)
Index: linux-2.6_dev/kernel/power/Kconfig
===
--- linux-2.6_dev.orig/kernel/power/Kconfig
+++ linux-2.6_dev/kernel/power/Kconfig
@@ -131,3 +131,5 @@ config SUSPEND_SMP
bool
depends on HOTPLUG_CPU && X86 && PM
default y
+
+source "kernel/power/fastoff/Kconfig"
Index: linux-2.6_dev/kernel/power/Makefile
===
--- linux-2.6_dev.orig/kernel/power/Makefile
+++ linux-2.6_dev/kernel/power/Makefile
@@ -8,3 +8,5 @@ obj-$(CONFIG_PM_LEGACY) += pm.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o disk.o snapshot.o swap.o user.o
obj-$(CONFIG_MAGIC_SYSRQ) += poweroff.o
+
+obj-$(CONFIG_FAST_POWER_OFF) += fastoff/
Index: linux-2.6_dev/kernel/power/fastoff/Kconfig
===
--- /dev/null
+++ linux-2.6_dev/kernel/power/fastoff/Kconfig
@@ -0,0 +1,13 @@
+#
+# Fast power off configuration
+#
+menu "Fast Power off"
+
+config FAST_POWER_OFF
+ bool "Fast power off support"
+ default y
+ depends on PM && SYSFS
+ ---help---
+ Say yes if you want core support for sysfs/power/fastoff
+
+endmenu
Index: linux-2.6_dev/kernel/power/fastoff/Makefile
===
--- /dev/null
+++ linux-2.6_dev/kernel/power/fastoff/Makefile
@@ -0,0 +1,8 @@
+#
+# Makefile for Fast Power off
+#
+# 15 Jan. 2007 Armin Kuster <[EMAIL PROTECTED]>
+#
+
+obj-$(CONFIG_FAST_POWER_OFF) := fpo.o
+
Index: linux-2.6_dev/kernel/power/fastoff/fpo.h
===
--- /dev/null
+++ linux-2.6_dev/kernel/power/fastoff/fpo.h
@@ -0,0 +1,27 @@
+#ifndef __FASTOFF_H__
+#define __FASTOFF_H__
+/*
+ * kernel/power/fastoff/fpo.h
+ *
+ * Author: Armin Kuster <[EMAIL PROTECTED], or [EMAIL PROTECTED]>
+ *
+ * 2006, 2007 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#define FPO_NAME_LEN 16
+
+struct fpo_driver {
+ char name[FPO_NAME_LEN];
+ int (*policy) (void);
+ struct list_head fpo_list;
+};
+
+extern int fastpoweroff_register(struct fpo_driver *fpo);
+extern void fastpoweroff_unregister(struct fpo_driver *fpo);
+extern void fastpoweroff_prepare(void);
+extern void fastpoweroff(void);
+extern void fastpoweroff_standby(void);
+#endif /* __FASTOFF_H__ */
Index: linux-2.6_dev/kernel/power/fastoff/fpo.c
===
--- /dev/null
+++ linux-2.6_dev/kernel/power/fastoff/fpo.c
@@ -0,0 +1,155 @@
+/*
+ * kernel/power/fastoff/fpo.c
+ *
+ * This provides a sysfs interface that allows the user to
+ * bypass running rc kill scripts in the advent the user
+ * needed to power down as fast as possible. A moduler scheme
+ * has been implimented so that a user can define how they want to
+ * shutdown.
+ *
+ * Author: Armin Kuster <[EMAIL PROTECTED], or [EMAIL PROTECTED]>
+ *
+ * 2006, 2007 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../power.h"
+#include "fpo.h"
+
+static LIST_HEAD(fastpoweroff_list);
+static DEFINE_MUTEX(fpo_mutex);
+
+extern void suspend_emergency_remount(void);
+
+static struct fpo_driver *__find_fastpoweroff(const char *name)
+{
+ struct fpo_driver *f;
+
+ list_for_each_entry(f, _list, fpo_list) {
+ if (!strnicmp(name, f->name, strlen(f->name))) {
+ return f;
+ }
+ }
+ return NULL;
+}
+
+int fastpoweroff_register(struct fpo_driver *fpo)
+{
+ int ret;
+
+ if (!fpo || !fpo->name || !fpo->policy)
+ return -EINVAL;
+
+ mutex_lock(_mutex);
+ ret = -EBUSY;
+ if
[PATCH 2/2] PM: fast power off - driver
My apologies, I cc'd the wrong list the first time around.
- Armin
---
Fastpoweroff default profile driver
signed-off-by: Armin Kuster <[EMAIL PROTECTED]>
---
kernel/power/fastoff/Kconfig |8
kernel/power/fastoff/Makefile |2 -
kernel/power/fastoff/fastoffdrv.c | 69 ++
3 files changed, 78 insertions(+), 1 deletion(-)
Index: linux-2.6_dev/kernel/power/fastoff/fastoffdrv.c
===
--- /dev/null
+++ linux-2.6_dev/kernel/power/fastoff/fastoffdrv.c
@@ -0,0 +1,69 @@
+/*
+ * kernel/power/fastoff/fastoffdrv.c
+ *
+ * This provides a sysfs interface that allows the user to
+ * bypass running rc kill scripts in the advent the user
+ * needed to power down as fast as possible. This could be
+ * in a low battery conditon and you want to try to keep
+ * data from being corrupted.
+ *
+ * Author: Armin Kuster <[EMAIL PROTECTED], or [EMAIL PROTECTED]>
+ *
+ * 2006, 2007 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "../power.h"
+#include "fpo.h"
+
+static int fsd_default_off(void)
+{
+ /*
+ * Actions taken:
+ *
+ *1. Freeze all user processes.
+ *
+ *2. Power off
+ *
+ *3. Power off devices
+ */
+
+ printk(KERN_EMERG "Fast Power Off initiated.\n");
+ fastpoweroff_prepare();
+ fastpoweroff();
+ fastpoweroff_standby();
+ return 1;
+}
+
+static struct fpo_driver fpo_default = {
+ .name = "default",
+ .policy = fsd_default_off,
+};
+
+static int __init fsd_default_init(void)
+{
+ int ret = 0;
+
+ if(( ret = fastpoweroff_register(_default)) < 0) {
+ printk(KERN_ERR "PM: Fastpoweroff: %s profile registation failed %d.\n",
+ fpo_default.name,ret);
+ goto errout;
+ }
+
+ printk(KERN_INFO "PM: Fastpoweroff, %s profile added\n",fpo_default.name);
+errout:
+ return ret;
+}
+
+module_init(fsd_default_init);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Armin Kuster <[EMAIL PROTECTED]>");
+
Index: linux-2.6_dev/kernel/power/fastoff/Kconfig
===
--- linux-2.6_dev.orig/kernel/power/fastoff/Kconfig
+++ linux-2.6_dev/kernel/power/fastoff/Kconfig
@@ -10,4 +10,12 @@ config FAST_POWER_OFF
---help---
Say yes if you want core support for sysfs/power/fastoff
+config FAST_POWER_DOWN
+ tristate "Fast power of profile"
+ depends on FAST_POWER_OFF
+ default n
+ ---help---
+ Say yes if want to bypass the rc kill scripts
+ and shut the machine down
+
endmenu
Index: linux-2.6_dev/kernel/power/fastoff/Makefile
===
--- linux-2.6_dev.orig/kernel/power/fastoff/Makefile
+++ linux-2.6_dev/kernel/power/fastoff/Makefile
@@ -5,4 +5,4 @@
#
obj-$(CONFIG_FAST_POWER_OFF) := fpo.o
-
+obj-$(CONFIG_FAST_POWER_DOWN) += fastoffdrv.o
[PATCH -MM]: updated e1000 - new hardware initialization code (replacement patch)
Andrew, Please pull: git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-mm to receive an updated version of the new e1000 hardware initialization code. This version incorporates both previously sent patches and replaces them, as well as adding some minor extra kdoc headers. The patch applies cleanly against jgarzik's netdev-2.6 #upstream commit 5ad0d383ddbf0d2fce43b8aac267a6c299fd2dff. the patch is also available in monolithic form over http: http://foo-projects.org/~sofar/e1000_git_new_device_init_code.patch.bz2 (166kb) or http://foo-projects.org/~sofar/e1000_git_new_device_init_code.patch (1.2mb) Cheers, Auke --- e1000: New device initialization code, fixes From: Jeb Cramer <[EMAIL PROTECTED]> This rewrite of the hardware initialization code splits up the driver low-level initialization code per chipset family. Several families exist with different initialization code per chipset, revision, and this allows us later to select only enable certain devices in the driver. The current code enables all previous drivers and thus doesn't change anything to the user, but is radically different internally. Mac and phy layers are also split, and everything is grouped in an API layer that the driver uses to interface the hardware. Support was added for a PCI-e 4-port Fibre version of the PRO/1000 PT quad port adapter (device 0x10a5). MTU changes on a downed interface require a phy commit to enact the new size immediately. Replace hard coded RAR numbers with constant. Add several function description and fix some small copy+paste errors in others. Fix link speed detection on PCI adapters showing wrong PCI bus speed. Fix laa detection. Rewrite tbi static for 82543. Fix mta list overflow. Don't unmap skb's twice in occasions, but set dma=0. Flatten dhcp generic function for readability. Change force phy speed duplex setup to be void and static. Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]> Signed-off-by: Bruce Allan <[EMAIL PROTECTED]> Signed-off-by: Jeb Cramer <[EMAIL PROTECTED]> Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000/Makefile| 19 drivers/net/e1000/e1000.h | 97 drivers/net/e1000/e1000_80003es2lan.c | 1377 + drivers/net/e1000/e1000_80003es2lan.h | 89 drivers/net/e1000/e1000_82540.c | 670 ++ drivers/net/e1000/e1000_82541.c | 1305 + drivers/net/e1000/e1000_82541.h | 86 drivers/net/e1000/e1000_82542.c | 551 ++ drivers/net/e1000/e1000_82543.c | 1643 ++ drivers/net/e1000/e1000_82543.h | 45 drivers/net/e1000/e1000_82571.c | 1127 drivers/net/e1000/e1000_82571.h | 42 drivers/net/e1000/e1000_api.c | 1174 drivers/net/e1000/e1000_api.h | 161 + drivers/net/e1000/e1000_defines.h | 1297 + drivers/net/e1000/e1000_ethtool.c | 470 +- drivers/net/e1000/e1000_hw.c | 9038 - drivers/net/e1000/e1000_hw.h | 3859 ++ drivers/net/e1000/e1000_ich8lan.c | 2427 + drivers/net/e1000/e1000_ich8lan.h | 110 drivers/net/e1000/e1000_mac.c | 1939 +++ drivers/net/e1000/e1000_mac.h | 84 drivers/net/e1000/e1000_main.c| 936 ++- drivers/net/e1000/e1000_manage.c | 388 + drivers/net/e1000/e1000_manage.h | 83 drivers/net/e1000/e1000_nvm.c | 859 +++ drivers/net/e1000/e1000_nvm.h | 61 drivers/net/e1000/e1000_osdep.h | 57 drivers/net/e1000/e1000_param.c | 100 drivers/net/e1000/e1000_phy.c | 1932 +++ drivers/net/e1000/e1000_phy.h | 159 + drivers/net/e1000/e1000_regs.h| 236 + 32 files changed, 19321 insertions(+), 13100 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ltt-dev] [PATCH 00/09] atomic.h : standardizing atomic primitives
On Sat, 27 Jan 2007 13:11:16 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > I am currently trying crosstool by Dan Kegel, it looks promising. > http://www.kegel.com/crosstool/ Yeah, I spent a frustrating two days with crosstool, managed to eke a number of cross-compilers out of it, but it took a *lot* of experimentation with gcc, glibc and binutils versions to get combinations which actually work. Good luck ;) There used to be someone who had a full suite, and who regularly published cross-compile results, but he stopped 6-12 months ago and I forget who that clever person was? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 7891] New: vdso page is no longer mapped for
Here is a patch that does what Andrew Morton suggested (plus some more
as explained below) .
Patch inline below and also attached in case there is whitespace
damage. Compile tested on i386 with make defconfig; make. If anyone
can test on other arches and provide feedback that'd be great.
Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>
- Give i386, x86_64, powerpc and sh a new
CONFIG_ARCH_HAS_SETUP_ADDITIONAL_PAGES
- Create a new include/linux/interp.h which has:
struct linux_binprm;
#ifdef CONFIG_ARCH_HAS_SETUP_ADDITIONAL_PAGES
extern int arch_setup_additional_pages(struct linux_binprm *bprm,
int executable_stack);
#else
static inline int arch_setup_additional_pages(struct linux_binprm *bprm,
int executable_stack)
{
return 0;
}
#endif
- include from binfmt_elf.c and binfmt_aout.c and from
all the files which implement arch_setup_additional_pages().
- Remove the #ifdef ARCH_HAS_SETUP_ADDITIONAL_PAGES from binfmt_elf.c
- Add the call to arch_setup_additional_pages() in binfmt_aout.h.
- EXPORT_SYMBOL(arch_setup_additional_pages) for all arches referred
above - binfmt_aout.c can be built as module on all architectures and
it needs to call arch_setup_additional_pages
- For x86_64 - remove
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
#define arch_setup_additional_pages syscall32_setup_pages
from ia32_binfmt.c and instead use arch_setup_additional_pages as an
exported wrapper over syscall32_setup_pages
diff -urN --exclude='cscope*' --exclude='*git*' --exclude='*.[sSoO]'
--exclude='*.gz' linux-2.6-us/arch/i386/Kconfig
linux-2.6-wk/arch/i386/Kconfig
--- linux-2.6-us/arch/i386/Kconfig 2007-01-26 18:49:36.0 -0500
+++ linux-2.6-wk/arch/i386/Kconfig 2007-01-26 18:56:29.0 -0500
@@ -625,6 +625,11 @@
config ARCH_POPULATES_NODE_MAP
def_bool y
+config ARCH_HAS_SETUP_ADDITIONAL_PAGES
+ bool
+ default y
+ depends on X86_32
+
source "mm/Kconfig"
config HIGHPTE
diff -urN --exclude='cscope*' --exclude='*git*' --exclude='*.[sSoO]'
--exclude='*.gz' linux-2.6-us/arch/i386/kernel/sysenter.c
linux-2.6-wk/arch/i386/kernel/sysenter.c
--- linux-2.6-us/arch/i386/kernel/sysenter.c2007-01-26 18:49:36.0
-0500
+++ linux-2.6-wk/arch/i386/kernel/sysenter.c2007-01-27 12:40:14.0
-0500
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -165,6 +166,7 @@
up_write(>mmap_sem);
return ret;
}
+EXPORT_SYMBOL(arch_setup_additional_pages);
const char *arch_vma_name(struct vm_area_struct *vma)
{
diff -urN --exclude='cscope*' --exclude='*git*' --exclude='*.[sSoO]'
--exclude='*.gz' linux-2.6-us/arch/powerpc/Kconfig
linux-2.6-wk/arch/powerpc/Kconfig
--- linux-2.6-us/arch/powerpc/Kconfig 2007-01-26 18:49:36.0 -0500
+++ linux-2.6-wk/arch/powerpc/Kconfig 2007-01-26 19:01:39.0 -0500
@@ -45,6 +45,11 @@
bool
default y
+config ARCH_HAS_SETUP_ADDITIONAL_PAGES
+ bool
+ default y
+ depends on PPC32 || PPC64
+
config ARCH_HAS_ILOG2_U64
bool
default y if 64BIT
diff -urN --exclude='cscope*' --exclude='*git*' --exclude='*.[sSoO]'
--exclude='*.gz' linux-2.6-us/arch/powerpc/kernel/vdso.c
linux-2.6-wk/arch/powerpc/kernel/vdso.c
--- linux-2.6-us/arch/powerpc/kernel/vdso.c 2007-01-26 18:49:36.0
-0500
+++ linux-2.6-wk/arch/powerpc/kernel/vdso.c 2007-01-27 12:39:39.0
-0500
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -305,6 +306,7 @@
up_write(>mmap_sem);
return rc;
}
+EXPORT_SYMBOL(arch_setup_additional_pages);
const char *arch_vma_name(struct vm_area_struct *vma)
{
diff -urN --exclude='cscope*' --exclude='*git*' --exclude='*.[sSoO]'
--exclude='*.gz' linux-2.6-us/arch/sh/Kconfig
linux-2.6-wk/arch/sh/Kconfig
--- linux-2.6-us/arch/sh/Kconfig2007-01-26 18:49:36.0 -0500
+++ linux-2.6-wk/arch/sh/Kconfig2007-01-26 19:04:00.0 -0500
@@ -67,6 +67,11 @@
bool
default n
+config ARCH_HAS_SETUP_ADDITIONAL_PAGES
+ bool
+ default y
+ depends on SUPERH
+
source "init/Kconfig"
menu "System type"
diff -urN --exclude='cscope*' --exclude='*git*' --exclude='*.[sSoO]'
--exclude='*.gz' linux-2.6-us/arch/sh/kernel/vsyscall/vsyscall.c
linux-2.6-wk/arch/sh/kernel/vsyscall/vsyscall.c
--- linux-2.6-us/arch/sh/kernel/vsyscall/vsyscall.c 2007-01-26
18:49:36.0 -0500
+++ linux-2.6-wk/arch/sh/kernel/vsyscall/vsyscall.c 2007-01-27
12:39:15.0 -0500
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
/*
* Should the kernel map a VDSO page into processes and pass its
@@ -125,6 +126,7 @@
up_write(>mmap_sem);
return ret;
}
+EXPORT_SYMBOL(arch_setup_additional_pages);
const char *arch_vma_name(struct vm_area_struct *vma)
{
diff -urN --exclude='cscope*'
Re: Abysmal disk performance, how to debug?
Willy Tarreau wrote: On Sat, Jan 20, 2007 at 02:56:20PM -0500, Stephen Clark wrote: Sunil Naidu wrote: On 1/20/07, Willy Tarreau <[EMAIL PROTECTED]> wrote: It is not expected to increase write performance, but it should help you do something else during that time, or also give more responsiveness to Ctrl-C. It is possible that you have fast and slow RAM, or that your video card uses shared memory which slows down some parts of memory which are not used anymore with those parameters. I did test some SATA drives, am getting these value for 2.6.20-rc5:- [EMAIL PROTECTED] ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s What can you suggest here w.r.t my RAM & disk? Willy Thanks, ~Akula2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi, whitebook vbi s96f core 2 duo t5600 2gb hitachi ATA HTS721060G9AT00 using libata time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 10.0092 seconds, 107 MB/s real0m10.196s user0m0.004s sys 0m3.440s You have too much RAM, it's possible that writes did not complete before the end of your measurement. Try this instead : $ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync I'm not sure that does what you think it does, the sync runs first, and data is still in the cache. Replace sync with "/bin/echo RAN" if you doubt me. What you want is this: sync; time bash -c "dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; sync" which will actually time the write with the time command. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Eric W. Biederman wrote: Auke Kok <[EMAIL PROTECTED]> writes: I highly doubt it - I've seen the problem even on this weeks git on x86_64. Moreover, I'm at home for the weekend and testing resources are limited :). I'll see what I can do Thanks. There may be more to it than what I suspect, but I could not reproduce it on x86_64. Now I may have missed something as I optimized my tested based on the fact that close and open are triggered when you up and down a network interface. so I didn't do a complete rmmod, (since my network driver wasn't modular). Since you have seen this on x86_64 I will look deeper. gah, strike that. my only x86_64 system here survived the test with latest git tree. my 386 system here has no msi devices and I can't reinstall my x86_64 system since it's headless, so I can't test anything until monday. I'll give it a full test again and see which 2.6.20rc kernels did fail, most likely a much older tree (I suspect). Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Auke Kok <[EMAIL PROTECTED]> writes: > I highly doubt it - I've seen the problem even on this weeks git on > x86_64. Moreover, I'm at home for the weekend and testing resources are > limited > :). I'll see what I can do Thanks. There may be more to it than what I suspect, but I could not reproduce it on x86_64. Now I may have missed something as I optimized my tested based on the fact that close and open are triggered when you up and down a network interface. so I didn't do a complete rmmod, (since my network driver wasn't modular). Since you have seen this on x86_64 I will look deeper. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] take 2: (was-kind-of: 3/5 SPI tx_default) 2.6.20-rc6
On Friday 26 January 2007 3:21 pm, David Brownell wrote:
> > FWIW, I defined it as a single bit in that patch, because that's
> > what my HW can do when the transmitter is disabled - and because
> > MOSI *is* a single-valued signal. ;-)
>
> I wouldn't mind a single bit flag either, saying whether to shift
> out all ones or all zeroes. The controller driver would morph it
> to something appropriate ... 0xff, 0x, etc.
In fact, how about this one instead? It uses a bit in spi->mode
since that's pretty easy to test. And while it doesn't get rid
of the multiple conditionals when the tx buffer is null, it does
let the other values be constants (0, ~0) that compilers like.
(I can update your patch #4, etc, to match.)
- Dave
Index: g26/include/linux/spi/spi.h
===
--- g26.orig/include/linux/spi/spi.h2007-01-26 15:16:26.0 -0800
+++ g26/include/linux/spi/spi.h 2007-01-26 17:07:30.0 -0800
@@ -71,6 +71,7 @@ struct spi_device {
#defineSPI_MODE_3 (SPI_CPOL|SPI_CPHA)
#defineSPI_CS_HIGH 0x04/* chipselect active
high? */
#defineSPI_LSB_FIRST 0x08/* per-word
bits-on-wire */
+#defineSPI_TX_10x10/* shift out ones on
rx-only */
u8 bits_per_word;
int irq;
void*controller_state;
@@ -296,8 +297,9 @@ extern struct spi_master *spi_busnum_to_
* the data being transferred; that may reduce overhead, when the
* underlying driver uses dma.
*
- * If the transmit buffer is null, zeroes will be shifted out
- * while filling rx_buf. If the receive buffer is null, the data
+ * If the transmit buffer is null, zeroes will be shifted out while
+ * filling rx_buf, unless SPI_TX_1 is set in spi->mode (in which case
+ * ones will be shifted out). If the receive buffer is null, the data
* shifted in will be discarded. Only "len" bytes shift out (or in).
* It's an error to try to shift out a partial word. (For example, by
* shifting out three bytes with word size of sixteen or twenty bits;
Index: g26/drivers/spi/spi_bitbang.c
===
--- g26.orig/drivers/spi/spi_bitbang.c 2007-01-26 17:29:55.0 -0800
+++ g26/drivers/spi/spi_bitbang.c 2007-01-26 17:36:17.0 -0800
@@ -73,10 +73,14 @@ static unsigned bitbang_txrx_8(
u8 *rx = t->rx_buf;
while (likely(count > 0)) {
- u8 word = 0;
+ u8 word;
if (tx)
word = *tx++;
+ else if (spi->mode & SPI_TX_1)
+ word = ~0;
+ else
+ word = 0;
word = txrx_word(spi, ns, word, bits);
if (rx)
*rx++ = word;
@@ -99,10 +103,14 @@ static unsigned bitbang_txrx_16(
u16 *rx = t->rx_buf;
while (likely(count > 1)) {
- u16 word = 0;
+ u16 word;
if (tx)
word = *tx++;
+ else if (spi->mode & SPI_TX_1)
+ word = ~0;
+ else
+ word = 0;
word = txrx_word(spi, ns, word, bits);
if (rx)
*rx++ = word;
@@ -125,10 +133,14 @@ static unsigned bitbang_txrx_32(
u32 *rx = t->rx_buf;
while (likely(count > 3)) {
- u32 word = 0;
+ u32 word;
if (tx)
word = *tx++;
+ else if (spi->mode & SPI_TX_1)
+ word = ~0;
+ else
+ word = 0;
word = txrx_word(spi, ns, word, bits);
if (rx)
*rx++ = word;
@@ -176,6 +188,8 @@ int spi_bitbang_setup_transfer(struct sp
}
EXPORT_SYMBOL_GPL(spi_bitbang_setup_transfer);
+#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_TX_1)
+
/**
* spi_bitbang_setup - default setup for per-word I/O loops
*/
@@ -192,8 +206,11 @@ int spi_bitbang_setup(struct spi_device
* just bitbang_txrx_le_cphaX() routines shifting the other way, and
* some hardware controllers also have this support.
*/
- if ((spi->mode & SPI_LSB_FIRST) != 0)
+ if (spi->mode & ~MODEBITS) {
+ dev_dbg(>dev, "unsupported SPI mode bits %04x\n",
+ spi->mode & ~MODEBITS);
return -EINVAL;
+ }
if (!cs) {
cs = kzalloc(sizeof *cs, GFP_KERNEL);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Re: [PATCH 1/2] take 2: (was-kind-of: 3/5 SPI tx_default) 2.6.20-rc6
On Saturday 27 January 2007 2:11 am, Hans-Peter Nilsson wrote: > > From: David Brownell <[EMAIL PROTECTED]> > > Date: Fri, 26 Jan 2007 15:21:15 -0800 > > > > > That flag could work in conjunction with a byte > > > > > > Or why not a 32-bit word! > > > > If a driver wants a repeating 32-bit pattern, they should just > > provide a properly initialized tx buffer. > > I'm suggesting the default_tx_word be able to fill out "common" > values of bits_per_word when > 8, else it'd be useless as a > 1-filler for larger sizes than byte. Making it a single bit > then wouldn't cater to your debug-with-scope use-case. That wasn't my idea, it was borrowed from someone else's debug arsenal. ;) In any case, I think that sort of debug assist doesn't need to stay in production system. See the patch I posted previously... - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On Sat, Jan 27, 2007 at 05:45:25PM +, Pavel Machek wrote:
> Hi!
>
> >Well, I do not think your kernel code is mergeable. But bits to enable
> >similar functionality in userspace probably would be mergeable.
> >
> > You said it :-)
> >
> > This patch exports to the user space the inactivity time (in msecs) of a
> > given
> > input device. Example follows:
>
> Looks okay to me. I guess you should sign it off, and ask Dmitry
> (input maintainer) for a merge?
The /proc/bus/input/devices has an extensible structure. You can just
add an "A:" line (for Activity) instead of adding a new proc file.
Anyway, I believe this should be also available through sysfs, if not
only there.
Also, the activity counters should IMO coincide with the event times
passed through /dev/input/event, and should not be jiffies based.
Ideally, both should be based on clock_gettime(CLOCK_MONOTONIC).
> > <0> $ cat /proc/bus/input/activity
> > 0011 0001 0001 ab41 1
> > 0011 0002 0008 3160799
> > 0011 0002 0008 7321 549991
> > 0019 0005 3160799
> > 0019 0001 3454901
> > 0010 104d 3160799
> > 0010 104d 2162833
> >
> > The device ordering matches the /proc/bus/input/devices one, anyway I
> > reported
> > also vendor, product, etc. Now the daemon is trivial...
>
> > @@ -482,6 +484,30 @@
> > return seq_open(file, _devices_seq_ops);
> > }
> >
> > +static int input_activity_seq_show(struct seq_file *seq, void *v)
> > +{
> > + struct input_dev *dev = container_of(v, struct input_dev, node);
> > +
> > + seq_printf(seq, "%04x %04x %04x %04x\t%u\n",
> > + dev->id.bustype, dev->id.vendor,
> > + dev->id.product, dev->id.version,
> > + jiffies_to_msecs((long) jiffies - (long)
> > dev->last_activity));
> > +
> > + return 0;
> > +}
> > +
> > +static struct seq_operations input_activity_seq_ops = {
> > + .start = input_devices_seq_start,
> > + .next = input_devices_seq_next,
> > + .stop = input_devices_seq_stop,
> > + .show = input_activity_seq_show,
> > +};
> > +
> > +static int input_proc_activity_open(struct inode *inode, struct file *file)
> > +{
> > + return seq_open(file, _activity_seq_ops);
> > +}
> > +
> > static struct file_operations input_devices_fileops = {
> > .owner = THIS_MODULE,
> > .open = input_proc_devices_open,
> > @@ -491,6 +517,15 @@
> > .release= seq_release,
> > };
> >
> > +static struct file_operations input_activity_fileops = {
> > + .owner = THIS_MODULE,
> > + .open = input_proc_activity_open,
> > + .poll = input_proc_devices_poll,
> > + .read = seq_read,
> > + .llseek = seq_lseek,
> > + .release= seq_release,
> > +};
> > +
> > static void *input_handlers_seq_start(struct seq_file *seq, loff_t *pos)
> > {
> > /* acquire lock here ... Yes, we do need locking, I knowi, I know... */
> > @@ -558,15 +593,23 @@
> > entry->owner = THIS_MODULE;
> > entry->proc_fops = _devices_fileops;
> >
> > - entry = create_proc_entry("handlers", 0, proc_bus_input_dir);
> > + entry = create_proc_entry("activity", 0, proc_bus_input_dir);
> > if (!entry)
> > goto fail2;
> >
> > entry->owner = THIS_MODULE;
> > + entry->proc_fops = _activity_fileops;
> > +
> > + entry = create_proc_entry("handlers", 0, proc_bus_input_dir);
> > + if (!entry)
> > + goto fail3;
> > +
> > + entry->owner = THIS_MODULE;
> > entry->proc_fops = _handlers_fileops;
> >
> > return 0;
> >
> > + fail3:remove_proc_entry("activity", proc_bus_input_dir);
> > fail2:remove_proc_entry("devices", proc_bus_input_dir);
> > fail1: remove_proc_entry("input", proc_bus);
> > return -ENOMEM;
> > diff -ur OLD/include/linux/input.h NEW/include/linux/input.h
> > --- OLD/include/linux/input.h 2007-01-26 16:59:38.0 +0100
> > +++ NEW/include/linux/input.h 2007-01-26 17:31:29.0 +0100
> > @@ -949,6 +949,8 @@
> > const char *uniq;
> > struct input_id id;
> >
> > + unsigned long last_activity;
> > +
> > unsigned long evbit[NBITS(EV_MAX)];
> > unsigned long keybit[NBITS(KEY_MAX)];
> > unsigned long relbit[NBITS(REL_MAX)];
>
> >
> > --
> > I don't think anyone should write their autobiography until after they're
> > dead. - Samuel Goldwyn
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
--
Vojtech Pavlik
Director SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Eric W. Biederman wrote:
Auke Kok <[EMAIL PROTECTED]> writes:
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
git-bisecting I've established that in between commit
04b9267b15206fc902a18de1f78de6c82ca47716 "Eric W. Biederman -- genirq: x86_64
irq: Remove the msi assumption that irq == vector" and commit
f29bd1ba68c8c6a0f50bd678bbd5a26674018f7c "Ingo Molnar -- genirq: convert the
x86_64 architecture to irq-chips" the behaviour broke.
The revisions in between seem to be dependent and give all sorts of other
issues, so it's rather hard for me to bisect that and give trustworthy results.
the e1000 driver hits the 256-mark cycle (I think - it consistently refuses to
do 500 msi irq/vector allocations which is my test case) and throws:
e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16
which is caused by a `if ((err = pci_enable_msi(adapter->pdev))) {` call from
the e1000 driver. It's rather easy to hit this mark with the new 4-port e1000
adapters :).
as for the e1000 code, I can say that even our oldest msi-enabled e1000 driver
works fine with 2.6.18 and under. All kernels from 2.6.19 fail consistently.
I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the
moment. Perhaps Eric Biederman can help?
Does this patch fix it for you? It looks like i386 vector allocate
did not have logic to look through the set of vectors more than once.
The code in this patch is a simplified version of what we have
on x86_64.
I highly doubt it - I've seen the problem even on this weeks git on x86_64.
Moreover, I'm at home for the weekend and testing resources are limited :). I'll
see what I can do
Auke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: git.kernel.org move (finally)... estimated week of Feb 5
Josh Boyer wrote: On 1/26/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Just for everyone's information... The git performance issues (especially) on kernel.org has been very frustrating, obviously. We're putting a dedicated git server in place hopefully the week of February 5. For the hardware geeks out there, do you know what kind of machine it will be? Sure... it's the DL380 G2 that used to be zeus.kernel.org. It's not ideal (in particular, I would have preferred a 64-bit machine), but it has the advantage that it's proven itself rock-solid over the years, it has all the hands-off management features, we have it, and it has 6 GB RAM. As far as filesystem is concerned, we might decide to use this machine to test out XFS. Haven't made the formal decision yet. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 question/problem [ot]
Also - when running software raid 10 - what's a good chunck size these days? Running raid 10 with 4 500 GB SATA2 drives with 16mb buffers? Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 question/problem [ot]
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Jan 27 2007 10:31, Marc Perkel wrote: > >--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > >> > >> >I'm a little stumped trying to set up raid 10. I > >> set > >> >it up and it worked but after a reboot it > forgets > >> my > >> >raid setup. > >> > >> Now, let's hear the name of the distribution you > >> use. > >> > >> BTW, is md1 also disappearing? > > > >Sorry about that. I'm using Fedora Core 6. /dev/md0 > >and /dev/md1, buth of which are raid 1 arrays > survive > >the reboot. But when I make a raid 0 out of those > two > >raid arrays that's what is vanishing. > > That's interesting. I am using Aurora Corona, and > all but md0 vanishes. > (Reason for that is that udev does not create the > nodes md1-md31 on > boot, so mdadm cannot assemble the arrays.) > What do you have to do to get UDEV to create /dev/md2? Is there a config file for that? Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: External module Makefile with generated C file
Jan Engelhardt wrote: ctracer_methods.o: ctracer_methods.c $(obj)/ctracer_methods.o: $(src)/ctracer_methods.c $(src)/ctracer_methods.c: ... I don't know if $(obj) or $(src) is the right thing, but something along these lines is required for OOT. Thanks, that did the trick, resulting Makefile: obj-m := ctracer.o ctracer-y := ctracer_methods.o ctracer_jprobe.o # Files generated that shall be removed upon make clean clean-files := ctracer_methods.c CLASS=sock KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules clean: rm -f *.mod.c *.ko *.o ctracer_methods.c $(obj)/ctracer_methods.o: ctracer_methods.c $(src)/ctracer_methods.c: ctracer /usr/lib/debug/lib/modules/$(shell uname -r)/vmlinux $(CLASS) > $@ - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-rt2 compile error on x86 -- undefined reference to `send_IPI_mask_bitmask'
Am Samstag, 27. Januar 2007 12:28 schrieb Frieder Bürzele: > Hi, > > I got the follow while trying to compile 2.6.20-rc6-rt2 > .config attached > > Greetz Frieder > > please CC me > > > CHK include/linux/version.h > CHK include/linux/utsrelease.h > CHK include/linux/compile.h > UPD include/linux/compile.h > CC init/version.o > LD init/built-in.o > GZIPkernel/config_data.gz > IKCFG kernel/config_data.h > CC kernel/configs.o > LD kernel/built-in.o > GEN .version > CHK include/linux/compile.h > UPD include/linux/compile.h > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > arch/i386/kernel/built-in.o: In function > `lapic_timer_broadcast':apic.c:(.text+0xccc8): undefined reference to > `send_IPI_mask_bitmask' > make: *** [.tmp_vmlinux1] Error 1 Enabling CONFIG_SMP works around that. Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 question/problem [ot]
On Jan 27 2007 10:31, Marc Perkel wrote: >--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: >> >> >I'm a little stumped trying to set up raid 10. I >> set >> >it up and it worked but after a reboot it forgets >> my >> >raid setup. >> >> Now, let's hear the name of the distribution you >> use. >> >> BTW, is md1 also disappearing? > >Sorry about that. I'm using Fedora Core 6. /dev/md0 >and /dev/md1, buth of which are raid 1 arrays survive >the reboot. But when I make a raid 0 out of those two >raid arrays that's what is vanishing. That's interesting. I am using Aurora Corona, and all but md0 vanishes. (Reason for that is that udev does not create the nodes md1-md31 on boot, so mdadm cannot assemble the arrays.) -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 question/problem [ot]
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > >I'm a little stumped trying to set up raid 10. I > set > >it up and it worked but after a reboot it forgets > my > >raid setup. > > Now, let's hear the name of the distribution you > use. > > BTW, is md1 also disappearing? > Sorry about that. I'm using Fedora Core 6. /dev/md0 and /dev/md1, buth of which are raid 1 arrays survive the reboot. But when I make a raid 0 out of those two raid arrays that's what is vanishing. Thanks for your help. Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: External module Makefile with generated C file
> ctracer_methods.o: ctracer_methods.c $(obj)/ctracer_methods.o: $(src)/ctracer_methods.c $(src)/ctracer_methods.c: ... I don't know if $(obj) or $(src) is the right thing, but something along these lines is required for OOT. -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ltt-dev] [PATCH 00/09] atomic.h : standardizing atomic primitives
* Andrew Morton ([EMAIL PROTECTED]) wrote: > I'm giving up. Someone should publish a suite of cross-compilers for us > so stuff like this doesn't need to happen. Hi Andrew, I am currently trying crosstool by Dan Kegel, it looks promising. http://www.kegel.com/crosstool/ I will let you know more when my cross compiler chain is set up. Mathieu -- OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
External module Makefile with generated C file
Sam, I'm trying to create a external module that involves generating one of the source files needed for the module, I'm using this Makefile: [EMAIL PROTECTED] ctracer_example]$ cat Makefile obj-m := ctracer.o ctracer-y := ctracer_methods.o ctracer_jprobe.o CLASS=sock KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules clean: rm -f *.mod.c *.ko *.o ctracer_methods.c # Files generated that shall be removed upon make clean clean-files := ctracer_methods.c ctracer_methods.o: ctracer_methods.c ctracer_methods.c: ctracer /usr/lib/debug/lib/modules/$(shell uname -r)/vmlinux $(CLASS) > ctracer_methods.c [EMAIL PROTECTED] ctracer_example]$ But I get this as the result: [EMAIL PROTECTED] ctracer_example]$ make make -C /lib/modules/2.6.19-1.2895.fc6/build SUBDIRS=/home/acme/git/pahole/ctracer_example modules make[1]: Entering directory `/usr/src/kernels/2.6.19-1.2895.fc6-i686' make[2]: *** No rule to make target `/home/acme/git/pahole/ctracer_example/ctracer_methods.o', needed by `/home/acme/git/pahole/ctracer_example/ctracer.o'. Stop. make[1]: *** [_module_/home/acme/git/pahole/ctracer_example] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.19-1.2895.fc6-i686' make: *** [default] Error 2 [EMAIL PROTECTED] ctracer_example]$ What is the stupid thing I'm doing? :-) - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 question/problem [ot]
>I'm a little stumped trying to set up raid 10. I set >it up and it worked but after a reboot it forgets my >raid setup. Now, let's hear the name of the distribution you use. BTW, is md1 also disappearing? -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Raid 10 question/problem [ot]
I'm a little stumped trying to set up raid 10. I set it up and it worked but after a reboot it forgets my raid setup. Created 2 raid 1 arrays in md0 and md1 and that works and survives a reboot. However - I created a raid 0 on /dev/md2 made up of /dev/md0 and /dev/md1 and it worked but it forgets it after I reboot. The device /dev/md2 fails to survive a reboot. Created the /etc/mdadm.conf file but that doesn't seem to have made a difference. What am I missing? Thanks in advance. Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6: known unfixed regressions (part 2)
On Sat, 27 Jan 2007, Adrian Bunk wrote: > > Unless I misunderstand this issue, we want this fixed before 2.6.20 > because otherwise many people might see this BUG message. The warnign was removed for other reasons, I'll re-instate it after 2.6.20 has been released so that we can resolve all filesystem things (as it is, right now, it's not any worse than it ever has been, and the kernel will shut up about filesystems doing something strange). But I think the Reiserfs problem already got fixed, and wouldn't warn any more even if the WARN_ON() was still there.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
Hi!
>Well, I do not think your kernel code is mergeable. But bits to enable
>similar functionality in userspace probably would be mergeable.
>
> You said it :-)
>
> This patch exports to the user space the inactivity time (in msecs) of a given
> input device. Example follows:
Looks okay to me. I guess you should sign it off, and ask Dmitry
(input maintainer) for a merge?
> <0> $ cat /proc/bus/input/activity
> 0011 0001 0001 ab41 1
> 0011 0002 0008 3160799
> 0011 0002 0008 7321 549991
> 0019 0005 3160799
> 0019 0001 3454901
> 0010 104d 3160799
> 0010 104d 2162833
>
> The device ordering matches the /proc/bus/input/devices one, anyway I reported
> also vendor, product, etc. Now the daemon is trivial...
> @@ -482,6 +484,30 @@
> return seq_open(file, _devices_seq_ops);
> }
>
> +static int input_activity_seq_show(struct seq_file *seq, void *v)
> +{
> + struct input_dev *dev = container_of(v, struct input_dev, node);
> +
> + seq_printf(seq, "%04x %04x %04x %04x\t%u\n",
> +dev->id.bustype, dev->id.vendor,
> +dev->id.product, dev->id.version,
> +jiffies_to_msecs((long) jiffies - (long)
> dev->last_activity));
> +
> + return 0;
> +}
> +
> +static struct seq_operations input_activity_seq_ops = {
> + .start = input_devices_seq_start,
> + .next = input_devices_seq_next,
> + .stop = input_devices_seq_stop,
> + .show = input_activity_seq_show,
> +};
> +
> +static int input_proc_activity_open(struct inode *inode, struct file *file)
> +{
> + return seq_open(file, _activity_seq_ops);
> +}
> +
> static struct file_operations input_devices_fileops = {
> .owner = THIS_MODULE,
> .open = input_proc_devices_open,
> @@ -491,6 +517,15 @@
> .release= seq_release,
> };
>
> +static struct file_operations input_activity_fileops = {
> + .owner = THIS_MODULE,
> + .open = input_proc_activity_open,
> + .poll = input_proc_devices_poll,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release= seq_release,
> +};
> +
> static void *input_handlers_seq_start(struct seq_file *seq, loff_t *pos)
> {
> /* acquire lock here ... Yes, we do need locking, I knowi, I know... */
> @@ -558,15 +593,23 @@
> entry->owner = THIS_MODULE;
> entry->proc_fops = _devices_fileops;
>
> - entry = create_proc_entry("handlers", 0, proc_bus_input_dir);
> + entry = create_proc_entry("activity", 0, proc_bus_input_dir);
> if (!entry)
> goto fail2;
>
> entry->owner = THIS_MODULE;
> + entry->proc_fops = _activity_fileops;
> +
> + entry = create_proc_entry("handlers", 0, proc_bus_input_dir);
> + if (!entry)
> + goto fail3;
> +
> + entry->owner = THIS_MODULE;
> entry->proc_fops = _handlers_fileops;
>
> return 0;
>
> + fail3: remove_proc_entry("activity", proc_bus_input_dir);
> fail2: remove_proc_entry("devices", proc_bus_input_dir);
> fail1: remove_proc_entry("input", proc_bus);
> return -ENOMEM;
> diff -ur OLD/include/linux/input.h NEW/include/linux/input.h
> --- OLD/include/linux/input.h 2007-01-26 16:59:38.0 +0100
> +++ NEW/include/linux/input.h 2007-01-26 17:31:29.0 +0100
> @@ -949,6 +949,8 @@
> const char *uniq;
> struct input_id id;
>
> + unsigned long last_activity;
> +
> unsigned long evbit[NBITS(EV_MAX)];
> unsigned long keybit[NBITS(KEY_MAX)];
> unsigned long relbit[NBITS(REL_MAX)];
>
> --
> I don't think anyone should write their autobiography until after they're
> dead. - Samuel Goldwyn
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc6: known regressions with patches (v2)
This email lists some known regressions in 2.6.20-rc6 compared to 2.6.19 with patches available. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: MIPS Malta: CONFIG_MTD=n compile error References : http://lkml.org/lkml/2007/1/25/122 Submitter : Jan Altenberg <[EMAIL PROTECTED]> Caused-By : Ralf Baechle <[EMAIL PROTECTED]> commit b228f4c54df37b53c6f364aa7f3efa4280bcc4f0 Handled-By : Jan Altenberg <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/1/25/122 Status : patch available Subject: NFS triggers WARN_ON() in invalidate_inode_pages2_range() References : http://bugzilla.kernel.org/show_bug.cgi?id=7826 Submitter : Andrew Clayton <[EMAIL PROTECTED]> Caused-By : Andrew Morton <[EMAIL PROTECTED]> commit 8258d4a574d3a8c01f0ef68aa26b969398a0e140 Handled-By : Trond Myklebust <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/1/24/323 Status : patch available - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix /sys/device/.../power/state regression
Hi! > > > > I thought the resolution was that fixing a few of those drivers > > > > should solve the problem Matthew needed resolved, and that in > > > > the meanwhile "rmmod drivername" should suffice. There also seemed > > > > to be agreement that power management for wireless devices needed > > > > more work; there might need to be a state between "down/off" and > > > > "configured and able to talk IP". > > > > > > It's certainly the case that fixing those drivers would result in a > > > better long-term situation - however, nobody currently seems to have any > > > interest in doing so... > > > > And the way these things work, unfortunately, is that merging your patch > > would ensure nobody ever gets such interest. Removing that "state" file > > (and its bogus infrastructure) has already taken a few years too long. > > > > No, we shouldn't just break stuff for our users in the hope that said > breakage will force some other developer to come in and fix things later. We are not breaking anything. We just make power consumption go up for _very_ small minority of our users... and we removed quite a few ways to oops a kernel that way. Drivers suspend/resume methods were not designed to be run at runtime; if you want to re-enable that, you should audit the drivers before reenable. And at that point, it should be easy to just do it properly. > We should revert the breakage-causing patch, with the expectation that its > submitter will ensure that all prerequisites are in place before it is > reapplied. Change breaking that was 'introduce suspend early to fix suspend on mac mini', by Linus, IIRC. So no, it is not easy to revert this one. > > You imply that it _was_ once supported, which is not true. Like any > > other bug (in this case "design bug"), it was there and could be abused. > > And like some other bugs, fixing it can trigger complaints from (ab)users. > > Could someone please explain in easy-to-understand terms what the > real-world impact of this bug is upon our users? How many are affected, > and under what circumstances, and with what effects? Oops, if you echo 3 to wrong file, or if you are hit by race. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc6: known unfixed regressions (v2) (part 2)
This email lists some known regressions in 2.6.20-rc6 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: problems with CD burning References : http://www.spinics.net/lists/linux-ide/msg06545.html Submitter : Uwe Bugla <[EMAIL PROTECTED]> Status : unknown Subject: pktcdvd fails with pata_amd References : http://bugzilla.kernel.org/show_bug.cgi?id=7810 http://lkml.org/lkml/2007/1/25/128 Submitter : Gerhard Dirschl <[EMAIL PROTECTED]> Caused-By : Christoph Hellwig <[EMAIL PROTECTED]> commit 3b00315799d78f76531b71435fbc2643cd71ae4c commit 406c9b605cbc45151c03ac9a3f95e9acf050808c Status : problem is being debugged Subject: powerpc64: performance monitor exception References : http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030045.html Submitter : Livio Soares <[EMAIL PROTECTED]> Caused-By : Paul Mackerras <[EMAIL PROTECTED]> commit d04c56f73c30a5e593202ecfcf25ed43d42363a2 Status : problem is being discussed Subject: BUG: at fs/inotify.c:172 set_dentry_child_flags() References : http://bugzilla.kernel.org/show_bug.cgi?id=7785 Submitter : Cijoml Cijomlovic Cijomlov <[EMAIL PROTECTED]> Handled-By : Nick Piggin <[EMAIL PROTECTED]> Status : problem is being debugged - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6: known unfixed regressions (part 2)
On Sat, Jan 27, 2007 at 06:28:01PM +0100, Adrian Bunk wrote: > On Fri, Jan 26, 2007 at 07:16:25PM +0100, Malte Schröder wrote: > > On Friday 26 January 2007 19:11, Adrian Bunk wrote: > > > Subject: BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs) > > > References : http://lkml.org/lkml/2007/1/7/117 > > > http://lkml.org/lkml/2007/1/10/202 > > > Submitter : Malte Schröder <[EMAIL PROTECTED]> > > > Handled-By : Vladimir V. Saveliev <[EMAIL PROTECTED]> > > > Nick Piggin <[EMAIL PROTECTED]> > > > Patch : http://lkml.org/lkml/2007/1/10/202 > > > Status : problem is being discussed > > > > This did not happen again. > > Unless I misunderstand this issue, we want this fixed before 2.6.20 > because otherwise many people might see this BUG message. /me looks: The warning was already removed post -rc6. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21 4/4] ehca: remove obsolete prototypes
Thanks, merged patches 3-4 for 2.6.21. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc6: known unfixed regressions (v2) (part 1)
This email lists some known regressions in 2.6.20-rc6 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: NULL pointer dereference at as_move_to_dispatch() References : http://lkml.org/lkml/2007/1/22/141 Submitter : Andrew Vasquez <[EMAIL PROTECTED]> Status : unknown Subject: reboot instead of powerdown (CONFIG_USB_SUSPEND) References : http://lkml.org/lkml/2006/12/25/40 http://bugzilla.kernel.org/show_bug.cgi?id=7828 Submitter : Berthold Cogel <[EMAIL PROTECTED]> François Valenduc <[EMAIL PROTECTED]> Handled-By : Alan Stern <[EMAIL PROTECTED]> Status : problem is being debugged Subject: usb somehow broken (CONFIG_USB_SUSPEND) References : http://lkml.org/lkml/2007/1/11/146 Submitter : Prakash Punnoor <[EMAIL PROTECTED]> Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Alan Stern <[EMAIL PROTECTED]> Status : problem is being debugged Subject: fix geode_configure() References : http://lkml.org/lkml/2007/1/9/216 Submitter : Lennart Sorensen <[EMAIL PROTECTED]> Caused-By : takada <[EMAIL PROTECTED]> commit e4f0ae0ea63caceff37a13f281a72652b7ea71ba Handled-By : takada <[EMAIL PROTECTED]> Lennart Sorensen <[EMAIL PROTECTED]> Status : patches are being discussed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/09] atomic.h : standardizing atomic primitives
* Andrew Morton ([EMAIL PROTECTED]) wrote: > On Thu, 25 Jan 2007 11:15:45 -0500 > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > > It mainly adds support for missing 64 bits cmpxchg and 64 bits atomic add > > unless. Therefore, principally 64 bits architectures are targeted by these > > patches. It also adds the complete list of atomic operations on the > > atomic_long > > type. > > OK, I fixed eight separate compile errors in this patch series and > now powerpc is being very ugly with a twisty maze of include dependencies. > > I'm giving up. Someone should publish a suite of cross-compilers for us > so stuff like this doesn't need to happen. Hi Andrew, This seems to be caused by the fact that I use inline functions for atomic_long_cmpxchg and atomic_long_xchg. I could simply use macros and this problem would fade away. I agree about the cross-compiler suite, it would be very useful here. Mathieu -- OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6: known unfixed regressions (part 2)
On Fri, Jan 26, 2007 at 07:16:25PM +0100, Malte Schröder wrote: > On Friday 26 January 2007 19:11, Adrian Bunk wrote: > > Subject: BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs) > > References : http://lkml.org/lkml/2007/1/7/117 > > http://lkml.org/lkml/2007/1/10/202 > > Submitter : Malte Schröder <[EMAIL PROTECTED]> > > Handled-By : Vladimir V. Saveliev <[EMAIL PROTECTED]> > > Nick Piggin <[EMAIL PROTECTED]> > > Patch : http://lkml.org/lkml/2007/1/10/202 > > Status : problem is being discussed > > This did not happen again. Unless I misunderstand this issue, we want this fixed before 2.6.20 because otherwise many people might see this BUG message. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded
[EMAIL PROTECTED] napisał(a): > The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz > git-scsi-misc.patch typo fix. drivers/scsi/NCR_D700.c: In function ‘NCR_D700_probe_one’: drivers/scsi/NCR_D700.c:203: error: ‘struct NCR_700_Host_Parameters’ has no member named ‘busrt_length’ make[2]: *** [drivers/scsi/NCR_D700.o] Błąd 1 make[1]: *** [drivers/scsi] Błąd 2 make: *** [drivers] Błąd 2 Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/) Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> --- linux-work-clean/drivers/scsi/NCR_D700.c2007-01-26 16:47:36.0 +0100 +++ linux-work/drivers/scsi/NCR_D700.c 2007-01-27 18:13:42.0 +0100 @@ -200,7 +200,7 @@ NCR_D700_probe_one(struct NCR_D700_priva hostdata->base = ioport_map(region, 64); hostdata->differential = (((1busrt_length = 8; + hostdata->burst_length = 8; /* and register the siop */ host = NCR_700_detect(_D700_driver_template, hostdata, p->dev); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: blacklist kernel boot option
* Jan Engelhardt <[EMAIL PROTECTED]> [2007-01-27 15:53]: > > On Jan 27 2007 02:22, Florian Schmidt wrote: > > > >i was wondering whether there exists any mechanism to blacklist modules > >from being loaded besides the typical etc/modprobe.d/blacklist type > >mechanisms. Sometimes you have a module oopsing because of faulty hw > >which cannot be removed rendering the system unbootable. And sometimes > >there's just no way to edit the modprobe blacklist because you cannot > >boot the box :) Basically i would like to setup a list of module names > >the kernel simply refuses to load.. > > > >blacklist=some_module,some_other_module,some_third_module > > >Does something exist? > > I think there was something like that although I can't remember > either what it was. brokenmodules=..., but that's SUSE's linuxrc. Regards, Bernhard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix /sys/device/.../power/state regression
Hi! > > This patch allows the bus driver to check whether a specific driver > > requires the split. If not, the 2.6.18 functionality is restored. It > > also alters feature-removals.txt to note that the deprecated > > functionality should not be removed until a replacement actually exists. > > That sounds like material for 2.6.20 as well as for 2.6.19.x. No. It re-enbles mechanism that never worked properly and that is known to oops the kernels. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: what kernel version embeds r1000 (RTL8168 Eth NICs)
* David Johnson <[EMAIL PROTECTED]> [2007-01-25 15:45]: > On Thursday 25 January 2007 09:36, Bernhard Walle wrote: > > > > The r8169 driver which is in the kernel should have the same > > functionality. > > > > It does indeed, but I think this support was only added recently; I believe > the first kernel version to support it was 2.6.19. Support is certainly in > the 2.6.20-rc kernels, as I'm using it. Yes, but what's the benefit if we would add r1000 in 2.6.21? Regards, Bernhard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix /sys/device/.../power/state regression
Hi!
> In 2.6.19, support for splitting driver suspend and resume callbacks
> into interrupt and non-interrupt contexts was added. Unfortunately, this
> broke /sys/device/.../power/state support for all devices. In the long
> run, this should be obsoleted by power management support in the
> individual drivers - however, in the case of network drivers (for
> example), currently only three drivers implement any sort of useful
> run-time power management.
Well... solution seems to be 'implement useful pm for more drivers'
not 'discourage people from doing so by re-enabling broken interface'.
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -9,7 +9,8 @@ be removed from this file.
> What:/sys/devices/.../power/state
> dev->power.power_state
> dpm_runtime_{suspend,resume)()
> -When:July 2007
> + bus->pm_has_noirq_stage()
> +When:Once alternative functionality has been implemented
.../power/state never worked properly. You have been warned and it is
going to be removed. It oopses kernels... while 'only' providing power
savings. If you are interested in power savings, please help doing
them right.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ahci: Marvell 6145 SATA support (preliminary)
Alan wrote: Were it not for the PATA and interrupt storm bits, I would say that Marvell 6145 works with a simple PCI ID addition. The 6101 driver should drive the 6145 pata port via the legacy registers They cannot co-exist, unfortunately. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git.kernel.org move (finally)... estimated week of Feb 5
On 1/26/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Just for everyone's information... The git performance issues (especially) on kernel.org has been very frustrating, obviously. We're putting a dedicated git server in place hopefully the week of February 5. For the hardware geeks out there, do you know what kind of machine it will be? josh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: 'asm' operand has impossible constraints
On Saturday 27 of January 2007 10:05:53 Avi Kivity wrote: > "g" appears to be equivalent to "rmi", if "i" is impossible, gcc is free > to use "r" or "m", no? `r' A register operand is allowed provided that it is in a general register. `g' Any register, memory or immediate integer operand is allowed, except for registers that are not general registers. so, it looks like g == !r for registers ( not general vs. general regs ). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Convert pci_module_init() to pci_register_driver()
Convert pci_module_init() to pci_register_driver().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
Diff'ed against the unpatched object-files, no difference
Has previously been sent to the maintainers, without respons
crypto/geode-aes.c |2 +-
net/hp100.c|2 +-
scsi/megaraid.c|2 +-
scsi/tmscsim.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
index 43a6839..31ea405 100644
--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -457,7 +457,7 @@ static struct pci_driver geode_aes_driver = {
static int __init
geode_aes_init(void)
{
- return pci_module_init(_aes_driver);
+ return pci_register_driver(_aes_driver);
}
static void __exit
diff --git a/drivers/net/hp100.c b/drivers/net/hp100.c
index 844c136..ff3663d 100644
--- a/drivers/net/hp100.c
+++ b/drivers/net/hp100.c
@@ -3034,7 +3034,7 @@ static int __init hp100_module_init(void)
goto out2;
#endif
#ifdef CONFIG_PCI
- err = pci_module_init(_pci_driver);
+ err = pci_register_driver(_pci_driver);
if (err && err != -ENODEV)
goto out3;
#endif
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
index 77d9d38..4fd4960 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -5072,7 +5072,7 @@ static int __init megaraid_init(void)
"megaraid: failed to create megaraid root\n");
}
#endif
- error = pci_module_init(_pci_driver);
+ error = pci_register_driver(_pci_driver);
if (error) {
#ifdef CONFIG_PROC_FS
remove_proc_entry("megaraid", _root);
diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c
index fa5382e..ce8845e 100644
--- a/drivers/scsi/tmscsim.c
+++ b/drivers/scsi/tmscsim.c
@@ -2681,7 +2681,7 @@ static int __init dc390_module_init(void)
printk (KERN_INFO "DC390: Using safe settings.\n");
}
- return pci_module_init(_driver);
+ return pci_register_driver(_driver);
}
static void __exit dc390_module_exit(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] pci_bus conversion to struct device
On Thu, Jan 18, 2007 at 01:00:44AM -0800, Greg KH wrote: > On Thu, Jan 18, 2007 at 09:14:06AM +0100, Martin Mares wrote: > > Hello! > > > > > I recommend we just delete the pci_bus class. I don't think it serves > > > any useful purpose. The bridge can be inferred frmo the sysfs hierarchy > > > (not to mention lspci will tell you). The cpuaffinity file should be > > > moved from the bus to the device -- it really doesn't make any sense to > > > talk about which cpu a bus is affine to, only a device. > > > > It doesn't seem to serve any useful purpose other than the affinity now, > > but I still think that it conceptually belongs there, because it makes > > sense to have per-bus attributes. For example, in the future we could > > show data width and signalling speed. Data width is kind of hard to figure out since it's negotiated per transaction. One could conceive of a device which only does 32-bit transactions to some addresses, and 64-bit transactions to others. What I've done in recent patches is make these kinds of attributes available per slot. > So, if it were to stay, where in the tree should it be? Hanging off of > the pci device that is the bridge? Or just placing these files within > the pci device directory itself, as it is the bridge. /sys/bus/pci/busses ? > There are also some "legacy io" binary sysfs files in these directories > for those platforms that support it (#ifdef HAVE_PCI_LEGACY), and I'm > guessing that there is some user for them out there, otherwise they > would not have been added... > > Hm, only ia64 enables that option. Matthew, do you care about those > files? I think they were added for Altix ... not sure who uses them. Maybe X? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
