Re: Kernel SCM saga..
On Wed, 2005-04-06 at 19:32 -0700, David Lang wrote: > On Thu, 7 Apr 2005, Martin Pool wrote: > > > I haven't tested importing all 60,000+ changesets of the current bk tree, > > partly because I don't *have* all those changesets. (Larry said > > previously that someone (not me) tried to pull all of them using bkclient, > > and he considered this abuse and blacklisted them.) > > pull the patches from the BK2CVS server. yes some patches are combined, > but it will get you in the ballpark. OK, I just tried that. I know there are scripts to resynthesize changesets from the CVS info but I skipped that for now and just pulled each day's work into a separate bzr revision. It's up to the end of March and still running. Importing the first snapshot (2004-01-01) took 41.77s user, 1:23.79 total. Each subsequent day takes about 10s user, 30s elapsed to commit into bzr. The speeds are comparable to CVS or a bit faster, and may be faster than other distributed systems. (This on a laptop with a 5400rpm disk.) Pulling out a complete copy of the tree as it was on a previous date takes about 14 user, 60s elapsed. I don't want to get too distracted by benchmarks now because there are more urgent things to do and anyhow there is still lots of scope for optimization. I wouldn't be at all surprised if those times could be more than halved. I just wanted to show it is in (I hope) the right ballpark. -- Martin signature.asc Description: This is a digitally signed message part
Re: [ANNOUNCE] April Release of LTP now Available
On Thu, Apr 07, 2005 at 10:52:01AM +1000, Paul Mackerras wrote: > Looks to me like gcc is objecting to our (ppc64's) _syscall2 > definition; Alan Modra (cc'd) can probably say what we're doing wrong. I can't spot anything wrong. Take a look at preprocessed source. -- Alan Modra IBM OzLabs - Linux Technology Centre - 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/
Low latency patches
Hi, I've recently come across Con Kolivas' isochronous scheduler and Ingo's RLIMIT_RT_CPU patch. I cannot comment on Ingo's patch, but I've been using Con's scheduler for a few days and I only have good things to say about it (latency is as good as running the process as root). The only thing missing is perhaps a way to enable the feature on a per-user basis (e.g. enable only for owner of the console), though I'm not sure whether it goes in kernel or user space. Are there any plans on merging some of that work? I think it would really help everyone doing audio (or other real-time stuff) on Linux. Jean-Marc P.S. Please include me in CC, I'm not subscribed. -- Jean-Marc Valin <[EMAIL PROTECTED]> Université de Sherbrooke - 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: init process freezed after run_init_process
Thanks for kindly reply, :) Jan Engelhardt wrote: This is my grub config: - root (hd0,0) kernel /bzImage.via.386 root=/dev/ram0 rw ramdisk=49152 initrd /initrd.gz - Does it work if you add " ramdisk=65536 init=/linuxrc " ? No. I got the same problem without linuxrc. As I mount ram0 as root, linuxrc is not necessary. Right? returned OK: initrd decompressed properly and open_exec returned non-zero. If you use k[g]db, you should be able to find out where the kernel actually hangs. After some digging, I found that the starting process of the VIA platform and the intel platform is exactly the same: 1) checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 9553k freed 2) loading drivers ... 3) RAMDISK: Compressed image found at block 0 kjournald starting. Commit interval 5 seconds EXT3 FS on ram0, internal journal EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem). Freeing unused kernel memory: 128k freed If I put the same hard disk into a intel platform without any change, it can start properly, loading the same initrd as rootfs. And also, if I remote the initrd config in VIA platform and mount my hard disk as rootfs, it also works properly. I missed some driver for VIA platform? Why it can work without initrd? My initrd has an invalid format? Why it can work on intel platform? I am really confused... After the starting process, the /sbin/init is loaded: I found that in a breakpoint of do_schedule. It keeps scheduling init and pdflush. I am still finding the way to debug the init process... Jan Engelhardt - 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: Kernel SCM saga..
On Wednesday 06 April 2005 21:40, Martin Pool wrote: > On Wed, 06 Apr 2005 23:39:11 +0400, Paul P Komkoff Jr wrote: > > http://bazaar-ng.org/ > > I'd like bazaar-ng to be considered too. It is not ready for adoption > yet, but I am working (more than) full time on it and hope to have it > be usable in a couple of months. > > bazaar-ng is trying to integrate a lot of the work done in other systems > to make something that is simple to use but also fast and powerful enough > to handle large projects. > > The operations that are already done are pretty fast: ~60s to import a > kernel tree, ~10s to import a new revision from a patch. Hi Martin, When I tried it, it took 13 seconds to 'bzr add' the 2.6.11.3 tree on a relatively slow machine. Regards, Daniel - 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.12-rc2-mm1
On Wed, Apr 06, 2005 at 02:27:49PM -0700, Andrew Morton wrote: > "Barry K. Nathan" <[EMAIL PROTECTED]> wrote: > > > > Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the > > problem goes away if I remove this patch: > > swsusp-enable-resume-from-initrd.patch > > That really helps, thanks. You're welcome. > The patch looks fairly innocent. I'll give up on this and cc the > developers. Yeah, it *seemed* innocent enough -- that's why I had to do a binary search on the 2.6.11-mm3 "series" file in order to find it as the culprit... > > (Recap of the problem in case this gets forwarded: Resume is almost > > instant without the apparently-guilty patch. With the patch, resume > > takes almost half an hour.) > > > > BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1: > > With that kernel, suspend is also ridiculously slow (speed is comparable > > to the slow resume with the aforementioned patch). 2.6.11-rc2 does not > > have that problem. > > Does reverting swsusp-enable-resume-from-initrd.patch fix this also? No. Reverting it from 2.6.12-rc2-mm1 (oops, I got the version number wrong in my previous mail -- and that should also be 2.6.12-rc2 not 2.6.11-rc2) speeds up resume to the original speed, but suspend is still ridiculously slow. Time to narrow things down again, I presume... > > Also, with 2.6.12-rc2-mm1, this computer happens to hit the bug where > > all the printk timestamps are 000.000 (don't take the # of > > digits too literally). Probably unrelated, but I may as well mention it. > > (System is an Athlon XP 2200+ with SiS chipset. I can't remember which > > model of SiS chipset.) > > Yes, sorry. Reverting > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_hpet-or-config_numa-systems.patch > will fix that one. I kind of figured that from another LKML discussion but I wasn't 100% sure that's what I should do. -Barry K. Nathan <[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.4.30-rc3 md/ext3 problems (ext3 gurus : please check)
Hi, At 23:20 05/04/06, Stephen C. Tweedie wrote: >Yes. But it is conventional to interpret a short write as being a >failure. Returning less bytes than were requested in the write >indicates that the rest failed. It just doesn't give the exact nature >of the failure (EIO vs ENOSPC etc.) For regular files, a short write is >never permitted unless there are errors of some description. When commit_write() FULLY succeed (requested bytes == returned bytes) but generic_osync_inode() return error due to I/O failure, current do_generic_file_write() cannot return error. I encountered above situation a lot under an I/O trouble condition . In ver 2.6.11, the return value of generic_osync_inode() is returned directry to user when I/O failure occur. thanks. - 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][RFC] disable built-in modules V2
> > -#define module_init(x) __initcall(x);
> > +#define module_init(x) __initcall(x); __module_init_disable(x);
>
> It would be better if there is brackets around them... like
>
> #define module_init(x) { __initcall(x); __module_init_disable(x); }
>
> then we know it wont break some code like
>
> if (..)
> module_init(x);
This is all completely academic, since module_init() is a declaration
that won't be inside any code, but in general it's better still to use
the do { } while (0) idiom like
#define module_init(x) do { __initcall(x); __module_init_disable(x); } while (0)
so it won't break code like
if (..)
module_init(x);
else
something_else();
(Yes, that code is nonsense but if you're going to nitpick, go all the way...)
- R.
-
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: x86-64 bad pmds in 2.6.11.6
On Thu, Mar 31, 2005 at 12:41:17PM +0200, Andi Kleen wrote: > On Wed, Mar 30, 2005 at 04:44:55PM -0500, Dave Jones wrote: > > [apologies to Andi for getting this twice, I goofed the l-k address > > the first time] > > > > > > I arrived at the office today to find my workstation had this spew > > in its dmesg buffer.. > > Looks like random memory corruption to me. > > Can you enable slab debugging etc.? > > > mm/memory.c:97: bad pmd 81004b017438(0038a5500a88). > > mm/memory.c:97: bad pmd 81004b017440(0003). > > mm/memory.c:97: bad pmd 81004b017448(773b). > > mm/memory.c:97: bad pmd 81004b017450(773c). > > etc.. I realised today that this happens every time X starts up for the first time. I did some experiments, and found that with 2.6.12rc1 it's gone. Either it got fixed accidentally, or its hidden now by one of the many changes in 4-level patches. I'll try and narrow this down a little more tomorrow, to see if I can pinpoint the exact -bk snapshot (may be tricky given they were broken for a while), as it'd be good to get this fixed in 2.6.11.x if .12 isn't going to show up any time soon. 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/
[patch] sched: consolidate sbe sbf
Hi Ingo,
What do you think of the following patch? I won't send the
whole series again, I'll queue them up with Andrew if you
think this one looks OK (which is the only major change).
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Consolidate balance-on-exec with balance-on-fork. This is made easy
by the sched-domains RCU patches.
As well as the general goodness of code reduction, this allows
the runqueues to be unlocked during balance-on-fork.
schedstats is a problem. Maybe just have balance-on-event instead
of distinguishing fork and exec?
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c 2005-04-07 02:39:21.0 +1000
+++ linux-2.6/kernel/sched.c2005-04-07 12:34:06.0 +1000
@@ -1022,8 +1022,57 @@ static int find_idlest_cpu(struct sched_
return idlest;
}
+/*
+ * sched_balance_self: balance the current task (running on cpu) in domains
+ * that have the 'flag' flag set. In practice, this is SD_BALANCE_FORK and
+ * SD_BALANCE_EXEC.
+ *
+ * Balance, ie. select the least loaded group.
+ *
+ * Returns the target CPU number, or the same CPU if no balancing is needed.
+ *
+ * preempt must be disabled.
+ */
+static int sched_balance_self(int cpu, int flag)
+{
+ struct task_struct *t = current;
+ struct sched_domain *tmp, *sd = NULL;
-#endif
+ for_each_domain(cpu, tmp)
+ if (tmp->flags & flag)
+ sd = tmp;
+
+ while (sd) {
+ cpumask_t span;
+ struct sched_group *group;
+ int new_cpu;
+
+ span = sd->span;
+ group = find_idlest_group(sd, t, cpu);
+ if (!group)
+ goto nextlevel;
+
+ new_cpu = find_idlest_cpu(group, cpu);
+ if (new_cpu == -1 || new_cpu == cpu)
+ goto nextlevel;
+
+ /* Now try balancing at a lower domain level */
+ cpu = new_cpu;
+nextlevel:
+ sd = NULL;
+ for_each_domain(cpu, tmp) {
+ if (cpus_subset(span, tmp->span))
+ break;
+ if (tmp->flags & flag)
+ sd = tmp;
+ }
+ /* while loop will break here if sd == NULL */
+ }
+
+ return cpu;
+}
+
+#endif /* CONFIG_SMP */
/*
* wake_idle() will wake a task on an idle cpu if task->cpu is
@@ -1241,8 +1290,17 @@ int fastcall wake_up_state(task_t *p, un
* Perform scheduler related setup for a newly forked process p.
* p is forked by current.
*/
-void fastcall sched_fork(task_t *p)
+void fastcall sched_fork(task_t *p, int clone_flags)
{
+ int cpu = smp_processor_id();
+
+#ifdef CONFIG_SMP
+ preempt_disable();
+ cpu = sched_balance_self(cpu, SD_BALANCE_FORK);
+ preempt_enable();
+#endif
+ set_task_cpu(p, cpu);
+
/*
* We mark the process as running here, but have not actually
* inserted it onto the runqueue yet. This guarantees that
@@ -1303,64 +1361,12 @@ void fastcall wake_up_new_task(task_t *
unsigned long flags;
int this_cpu, cpu;
runqueue_t *rq, *this_rq;
-#ifdef CONFIG_SMP
- struct sched_domain *tmp, *sd = NULL;
-#endif
rq = task_rq_lock(p, );
BUG_ON(p->state != TASK_RUNNING);
this_cpu = smp_processor_id();
cpu = task_cpu(p);
-#ifdef CONFIG_SMP
- for_each_domain(cpu, tmp)
- if (tmp->flags & SD_BALANCE_FORK)
- sd = tmp;
-
- if (sd) {
- cpumask_t span;
- int new_cpu;
- struct sched_group *group;
-
-again:
- schedstat_inc(sd, sbf_cnt);
- span = sd->span;
- cpu = task_cpu(p);
- group = find_idlest_group(sd, p, cpu);
- if (!group) {
- schedstat_inc(sd, sbf_balanced);
- goto nextlevel;
- }
-
- new_cpu = find_idlest_cpu(group, cpu);
- if (new_cpu == -1 || new_cpu == cpu) {
- schedstat_inc(sd, sbf_balanced);
- goto nextlevel;
- }
-
- if (cpu_isset(new_cpu, p->cpus_allowed)) {
- schedstat_inc(sd, sbf_pushed);
- set_task_cpu(p, new_cpu);
- task_rq_unlock(rq, );
- rq = task_rq_lock(p, );
- cpu = task_cpu(p);
- }
-
- /* Now try balancing at a lower domain level */
-nextlevel:
- sd = NULL;
- for_each_domain(cpu, tmp) {
- if (cpus_subset(span, tmp->span))
- break;
- if (tmp->flags & SD_BALANCE_FORK)
-
Kernel oops and debugging (help wanted)
Hi I recently installed a new kernel 2.6.11 with some netfilter patches, I also upgraded iproute2. No I have been getting oops like this one Apr 6 15:46:24 sydlxfw01 kernel: Unable to handle kernel NULL pointer dereference at virtual address 0221 Apr 6 15:46:24 sydlxfw01 kernel: printing eip: Apr 6 15:46:24 sydlxfw01 kernel: c01ebec0 Apr 6 15:46:24 sydlxfw01 kernel: *pde = Apr 6 15:46:24 sydlxfw01 kernel: Oops: 0002 [#1] Apr 6 15:46:24 sydlxfw01 kernel: PREEMPT Apr 6 15:46:24 sydlxfw01 kernel: Modules linked in: rtc nvidia tun l2cap bluetooth nfsd exportfs lockd sunrpc ipt_ULOG defl ate twofish serpent aes_i586 blowfish des sha256 sha1 crypto_null xfrm_user ipcomp esp4 ah4 af_key lp autofs4 ppp_deflate zl ib_deflate bsd_comp capability commoncap ip_nat_ftp ip_conntrack_ftp binfmt_misc binfmt_aout raw ppp_async crc_ccitt ppp_gen eric slhc eepro100 eth1394 bridge atm sch_tbf sch_sfq sch_prio af_packet ip6t_limit ip6t_LOG ip6t_mac ip6t_MARK ip6table_man gle ip6table_filter ip6_tables md5 ipv6 ipt_TARPIT ipt_limit ipt_REJECT ipt_LOG ipt_mac ipt_mark ipt_MASQUERADE iptable_nat ipt_owner ipt_MARK ipt_state ip_conntrack iptable_mangle iptable_filter ip_tables tsdev psmouse parport_pc parport evdev flo ppy pcspkr sundance mii crc32 ohci1394 ieee1394 snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core ehci_hcd usbhid usblp uhci_hcd intel_agp intel_mch_agp agpgart i8xx_tco ide_cd cd rom usb_storage usbcore sg aic7xxx id Apr 6 15:46:24 sydlxfw01 kernel: _disk ide_generic via82cxxx trm290 triflex slc90e66 sis5513 siimage serverworks sc1200 rz1 000 pdc202xx_old opti621 ns87415 hpt366 hpt34x generic cy82c693 cs5530 cs5520 cmd64x amd74xx alim15x3 aec62xx pdc202xx_new u nix ext2 ext3 jbd mbcache dm_mod raid5 xor raid1 md sd_mod ata_piix libata scsi_mod piix ide_core Apr 6 15:46:24 sydlxfw01 kernel: CPU:0 Apr 6 15:46:24 sydlxfw01 kernel: EIP: 0060:[tty_ldisc_ref_wait+144/192]Tainted: P VLI Apr 6 15:46:24 sydlxfw01 kernel: EFLAGS: 00210286 (2.6.11-1-ntf) Apr 6 15:46:24 sydlxfw01 kernel: EIP is at tty_ldisc_ref_wait+0x90/0xc0 Apr 6 15:46:24 sydlxfw01 kernel: eax: 0221 ebx: e895b00c ecx: c01f3ce0 edx: c8751000 Apr 6 15:46:24 sydlxfw01 kernel: esi: edi: 00200246 ebp: esp: ded97e94 Apr 6 15:46:24 sydlxfw01 kernel: ds: 007b es: 007b ss: 0068 Apr 6 15:46:24 sydlxfw01 kernel: Process screen (pid: 17625, threadinfo=ded96000 task=d8b5da20) Apr 6 15:46:24 sydlxfw01 kernel: Stack: c01ebf06 e895b000 e895b000 c01ec558 e895b000 c8751000 c01f3cfd Apr 6 15:46:24 sydlxfw01 kernel:e895b000 c8751000 c01f050b c8751000 c01f28d8 c8751000 e5f64f43 0049 Apr 6 15:46:24 sydlxfw01 kernel: c02d4c40 ded96000 c875193c 7fff 0001 Apr 6 15:46:24 sydlxfw01 kernel: Call Trace: Apr 6 15:46:24 sydlxfw01 kernel: [tty_ldisc_ref+22/48] tty_ldisc_ref+0x16/0x30 Apr 6 15:46:24 sydlxfw01 kernel: [tty_wakeup+72/112] tty_wakeup+0x48/0x70 Apr 6 15:46:24 sydlxfw01 kernel: [pty_unthrottle+29/48] pty_unthrottle+0x1d/0x30 Apr 6 15:46:24 sydlxfw01 kernel: [check_unthrottle+59/64] check_unthrottle+0x3b/0x40 Apr 6 15:46:24 sydlxfw01 kernel: [read_chan+1080/2016] read_chan+0x438/0x7e0 Apr 6 15:46:24 sydlxfw01 kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 Apr 6 15:46:24 sydlxfw01 last message repeated 2 times Apr 6 15:46:24 sydlxfw01 kernel: [tty_read+246/288] tty_read+0xf6/0x120 Apr 6 15:46:24 sydlxfw01 kernel: [vfs_read+229/352] vfs_read+0xe5/0x160 Apr 6 15:46:24 sydlxfw01 kernel: [sys_read+81/128] sys_read+0x51/0x80 Apr 6 15:46:24 sydlxfw01 kernel: [sysenter_past_esp+82/117] sysenter_past_esp+0x52/0x75 Apr 6 15:46:24 sydlxfw01 kernel: Code: 54 24 34 90 8d b4 26 00 00 00 00 b9 02 00 00 00 89 fa b8 2c b2 30 c0 e8 cf 3a f4 ff 89 1c 24 e8 07 ff ff ff 85 c0 75 07 e8 fe ed <09> 00 eb dc 89 fa b8 2c b2 30 c0 e8 f0 3b f4 ff 8b 7b 54 85 ff this is followed by these Apr 6 15:46:24 sydlxfw01 kernel: ve! Apr 6 15:46:24 sydlxfw01 kernel: release_dev: ptm5: read/write wait queue active! Apr 6 15:46:29 sydlxfw01 last message repeated 119552 times Apr 6 15:46:29 sydlxfw01 kernel: ve! Apr 6 15:46:29 sydlxfw01 kernel: release_dev: ptm5: read/write wait queue active! I was wondering how I decode this to the location that cause the problem do I do a search through the source tree (still have it - built from debian kernel-source-2.6.11-1) and look for tty_ldisc_ref_wait - I presume the error occured 0x90 bytes into the code ? Or how do I work out who to contact to say there might be a problem. Thanks Alex signature.asc Description: Digital signature
uid of person who mounts and user unmount
smbfs displays the uid of the mounter in show_mounts (viewable in /proc/mounts ) and this would allow a setuid unmount program to check the uid of the mounter via /proc/mounts (there is also an ioctl which does something similar). Is this approach secure enough? I slightly prefer an approach in which a program that wishes to check if the current->uid matches that of the mounter (or that uid which was specified on the mount command option and which was saved in the fs's superblock) simply calls an empty ioctl to the fs - which returns yes/no (the uid of the current process, matches the uid of the process that did the mount or not, this requires the fs to save the uid at mount but presumably has the disadvantage of opening a file to get a handle that you can use for the ioctl). There are other ways to achieve somewhat similar effect - of allowing user mounts and unmounts via fstab - but I have had users request a way to do this via a setuid filesystem specific umount util. Is there a security issue with displaying the uid of the mounter via the fs's show_mounts (shows up in /proc/mounts) - 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: Kernel SCM saga..
On Thu, 7 Apr 2005, Martin Pool wrote: I haven't tested importing all 60,000+ changesets of the current bk tree, partly because I don't *have* all those changesets. (Larry said previously that someone (not me) tried to pull all of them using bkclient, and he considered this abuse and blacklisted them.) pull the patches from the BK2CVS server. yes some patches are combined, but it will get you in the ballpark. David Lang I have been testing pulling in release and rc patches, and it scales to that level. It probably could not handle 60,000 changesets yet, but there is a plan to get there. In the interim, although it cannot handle the whole history forever it can handle large trees with moderate numbers of commits -- perhaps as many as you might deal with in developing a feature over a course of a few months. The most sensible place to try out bzr, if people want to, is as a way to keep your own revisions before mailing a patch to linus or the subsystem maintainer. -- Martin - 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/ -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - 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: scheduler/SCHED_FIFO behaviour
On Thu, 2005-04-07 at 07:11 +0530, Arun Srinivas wrote: > I am not sure if my question was clear enough or I couldnt interpret you > answer correctly.(If it was the case I apologise for that). > > My question is, as I said I am measuring the schedule time difference > between my 2 of my SCHED_FIFO process in schedule() .But, I get only one set > of readings (i.e., schedule() is being called once which implies my process > is being scheduled only once and run till completion) > > Also, as I said my interrupts are being processed during this time.I > inspected /proc/interrupts for this.So, my question was if interrupts heve > been processed several times the 2 SCHED_FIFO process which has been > interrupted must have been resecheduled several times and for this upon > returning from the interrupt handler the schedule() function must have been > called several times to schedule the 2 process which were running.But, as I > said I get only one reading?? > > >From your reply, I come to understand that when an interrupt interrupts my > user process.it runs straight way but upon return from the interrupt > handler does it not call schedule() to again resume my interrupted process? Exactly! Even going back to a user process, if that process is the highest priority process than it does not need to call schedule. Actually the only time it would call schedule, is if the interrupt called wake_up_process, or did something that needed the need_resched for the running task set. Even if wake_up_process was called, if the process was not higher in priority than the running process, then it would not preempt it. So... 1) Task running in user land. 2) interrupt goes off, switch to kernel mode. 3) execute interrupt service routine. 4) ISR calls wake_up_process (most likely on ksoftirqd) 5) ksoftirqd not as high a priority as running process (don't set need_resched) 6) return from interrupt. need_resched not set. 7) go back to user process running in user land. There, is that clear. schedule is never called. Set ksoftirqd higher in priority than your tasks, and you might start seeing scheduling. But sometimes the functions needed to execute are done on return from interrupt and not though ksoftirqd, so you still might not see a schedule. But I'm sure you will. -- Steve - 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: Kernel SCM saga..
On Wed, 06 Apr 2005 21:47:27 -0400, Jeff Garzik wrote: >> The operations that are already done are pretty fast: ~60s to import a >> kernel tree, ~10s to import a new revision from a patch. > > By "importing", are you saying that importing all 60,000+ changesets of > the current kernel tree took only 60 seconds? Now that would be impressive. No, I mean this: % bzcat ../linux.pkg/patch-2.5.14.bz2| patch -p1 % time bzr add -v . (find any new non-ignored files; deleted files automatically noticed) 6.06s user 0.41s system 89% cpu 7.248 total % time bzr commit -v -m 'import 2.5.14' 7.71s user 0.71s system 65% cpu 12.893 total (OK, a bit slower in this case but it wasn't all in core.) This is only v0.0.3, but I think the interface simplicity and speed compares well. I haven't tested importing all 60,000+ changesets of the current bk tree, partly because I don't *have* all those changesets. (Larry said previously that someone (not me) tried to pull all of them using bkclient, and he considered this abuse and blacklisted them.) I have been testing pulling in release and rc patches, and it scales to that level. It probably could not handle 60,000 changesets yet, but there is a plan to get there. In the interim, although it cannot handle the whole history forever it can handle large trees with moderate numbers of commits -- perhaps as many as you might deal with in developing a feature over a course of a few months. The most sensible place to try out bzr, if people want to, is as a way to keep your own revisions before mailing a patch to linus or the subsystem maintainer. -- Martin - 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/6] freepgt2: arm26 FIRST_USER_ADDRESS PAGE_SIZE
Hugh Dickins wrote: ARM26 define FIRST_USER_ADDRESS as PAGE_SIZE (beyond the machine vectors when they are mapped low), and use that definition in place of locally defined MIN_MAP_ADDR. Previously, ARM26 permitted user mappings at 0 if the machine vectors were mapped high; but that's inconsistent with ARM, and FIRST_USER_ADDRESS would then have to be determined at runtime. Let's fix it at PAGE_SIZE throughout the architecture. This is correct because ARM26 cant map vectors high at all. applied. - 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] r128_state.c: break missing in switch statement (fwd)
Hi Andrew/Linus,
Can you make sure this goes into 2.6.12? until you sort out the bk
thing I'll adopt this approach :-)
Dave.
drm: fix r128_state.c switch statements..
in drivers/char/drm/r128_state.c (linux-2.6.12-rc2), some breaks are
missing in the switch statement. See trivial fix below.
Signed-off-by: Hansjoerg Lipp <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
diff -urp linux-2.6.12-rc2/drivers/char/drm/r128_state.c
linux-2.6.12-rc2-fix/drivers/char/drm/r128_state.c
--- linux-2.6.12-rc2/drivers/char/drm/r128_state.c 2005-04-06
13:18:05.0 +0200
+++ linux-2.6.12-rc2-fix/drivers/char/drm/r128_state.c 2005-04-06
13:23:50.0 +0200
@@ -1549,12 +1549,16 @@ static int r128_cce_depth( DRM_IOCTL_ARG
switch ( depth.func ) {
case R128_WRITE_SPAN:
ret = r128_cce_dispatch_write_span( dev, );
+ break;
case R128_WRITE_PIXELS:
ret = r128_cce_dispatch_write_pixels( dev, );
+ break;
case R128_READ_SPAN:
ret = r128_cce_dispatch_read_span( dev, );
+ break;
case R128_READ_PIXELS:
ret = r128_cce_dispatch_read_pixels( dev, );
+ break;
}
COMMIT_RING();
-
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] CON_CONSDEV bit not set correctly on last console
On Wed, Apr 06, 2005 at 03:53:17PM -0700, Andrew Morton wrote: | Greg Edwards <[EMAIL PROTECTED]> wrote: | > | > According to include/linux/console.h, CON_CONSDEV flag should be set on | > the last console specified on the boot command line: | > | > 86 #define CON_PRINTBUFFER (1) | > 87 #define CON_CONSDEV (2) /* Last on the command line */ | > 88 #define CON_ENABLED (4) | > 89 #define CON_BOOT(8) | > | > This does not currently happen if there is more than one console specified | > on the boot commandline. Instead, it gets set on the first console on the | > command line. This can cause problems for things like kdb that look for | > the CON_CONSDEV flag to see if the console is valid. | > | > Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next | > preferred console at unregister time if the console being unregistered | > currently has that bit set. | > | > Example (from sn2 ia64): | > | > elilo vmlinuz root= console=ttyS0 console=ttySG0 | > | > in this case, the flags on ttySG console struct will be 0x4 (should be | > 0x6). | > | > Attached patch against bk fixes both issues for the cases I looked at. It | > uses selected_console (which gets incremented for each console specified | > on the command line) as the indicator of which console to set CON_CONSDEV | > on. When adding the console to the list, if the previous one had | > CON_CONSDEV set, it masks it out. Tested on ia64 and x86. | | The `console=a console=b' behaviour seem basically random to me :(. And it | gets re-randomised on a regular basis. | | I wonder if we should leave the existing behaviour alone (continue to set | CON_CONSDEV on the first console) and just change the documentation? | That'll minimise the disruption which we cause. The problem with the current behavior is it breaks overriding the default from the boot line. In the ia64 case, there may be a global append line defining console=a in elilo.conf. Then you want to boot your kernel, and want to override the default by passing console=b on the boot line. elilo constructs the kernel cmdline by starting with the value of the global append line, then tacks on whatever else you specify, which puts console=b last. You can always edit the elilo.conf and change the global value, but that seems like a pretty big hammer for something you may just want to test. Greg - 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/
we can work together
Dear Sir, You will be surprise to see this message but I got your information through Spartanburg, area chamber of commerce USA. My name is Howard Jones, a Chief Auditor, during my last auditing in the United States of America with JPMORGANCHASE CO.in New York, we realized the sum $35.5million owned by one Patric Zuma from Egypt who died during the terrorist attack of Sept.11,2001 in the world trade center. All efforts,which have been made to reach the relatives of Mr.Patric Zuma for the past two years, have not yielded any positive result. It was later gathered that Mr.Zuma|s divorced wife and only son died in the September 11 bombing of the World Trade center in New York the same - 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/
we can work together
Dear Sir, You will be surprise to see this message but I got your information through Spartanburg, area chamber of commerce USA. My name is Howard Jones, a Chief Auditor, during my last auditing in the United States of America with JPMORGANCHASE CO.in New York, we realized the sum $35.5million owned by one Patric Zuma from Egypt who died during the terrorist attack of Sept.11,2001 in the world trade center. All efforts,which have been made to reach the relatives of Mr.Patric Zuma for the past two years, have not yielded any positive result. It was later gathered that Mr.Zuma|s divorced wife and only son died in the September 11 bombing of the World Trade center in New York the same - 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: Kernel SCM saga..
On Thu, Apr 07, 2005 at 11:40:23AM +1000, Martin Pool wrote: > On Wed, 06 Apr 2005 23:39:11 +0400, Paul P Komkoff Jr wrote: > > > http://bazaar-ng.org/ > > I'd like bazaar-ng to be considered too. It is not ready for adoption > yet, but I am working (more than) full time on it and hope to have it > be usable in a couple of months. > > bazaar-ng is trying to integrate a lot of the work done in other systems > to make something that is simple to use but also fast and powerful enough > to handle large projects. > > The operations that are already done are pretty fast: ~60s to import a > kernel tree, ~10s to import a new revision from a patch. By "importing", are you saying that importing all 60,000+ changesets of the current kernel tree took only 60 seconds? 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: scheduler/SCHED_FIFO behaviour
I am not sure if my question was clear enough or I couldnt interpret you answer correctly.(If it was the case I apologise for that). My question is, as I said I am measuring the schedule time difference between my 2 of my SCHED_FIFO process in schedule() .But, I get only one set of readings (i.e., schedule() is being called once which implies my process is being scheduled only once and run till completion) Also, as I said my interrupts are being processed during this time.I inspected /proc/interrupts for this.So, my question was if interrupts heve been processed several times the 2 SCHED_FIFO process which has been interrupted must have been resecheduled several times and for this upon returning from the interrupt handler the schedule() function must have been called several times to schedule the 2 process which were running.But, as I said I get only one reading?? From your reply, I come to understand that when an interrupt interrupts my user process.it runs straight way but upon return from the interrupt handler does it not call schedule() to again resume my interrupted process? Please help. Thanks arun From: Steven Rostedt <[EMAIL PROTECTED]> To: Arun Srinivas <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], LKML Subject: Re: scheduler/SCHED_FIFO behaviour Date: Mon, 04 Apr 2005 23:33:05 -0400 On Tue, 2005-04-05 at 07:46 +0530, Arun Srinivas wrote: > > So, what I want from the above code is whenever process1 or process2 is > being scheduled measure the time and print the timedifference. But, when I > run my 2 processes as SCHED_FIFO processes i get only one set of > readingsindicating they have been scheduled only once and run till > completion. > > But, as we saw above if interrupts have been processed they must have been > scheduled several times(i.e., schedule() called several times). Is my > measurement procedure not correct? No! Interrupts are not scheduled. When an interrupt goes off, the interrupt service routine (ISR) is executed. It doesn't need to be scheduled. It runs right where it interrupted the CPU. That's why you need to be careful about protecting data that ISRs manipulate with spin_lock_irqsave. This not only protects against multiple CPUs, but turns off interrupts so that an interrupt wont be called and one of the ISRs modify the data you need to be atomic. Your tasks are running and will be interrupted by an ISR, on return from the routine, a check is made to see if your tasks should be preempted. But since they are the highest running tasks and in FIFO mode, the check determines that schedule should not be called. So you will not see any schedules while your tasks are running. Now, if you where running Ingo's RT patch with PREEMPT_HARDIRQ enabled, and your tasks were of lower priority than the ISR thread handlers, then you would see the scheduling. Maybe that is what you want? -- Steve _ Send money to India http://ads.mediaturf.net/event.ng/Type=click=17307=44925=9763=9763=414,868,1093,2385=http:%2F%2Fwww.icicibanknripromotions.com%2Fm2i_feb%2Fnri_M2I_feb.jsp%3Fadid%3D44925%26siteid%3D1093%26flightid%3D17307 Get a FREE 30 minute India Calling Card. - 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/
hard lockup on nx5000 laptop with 2.6.11+hack and FC2's 2.6.10-1.770_FC2
Several wierd things with my laptop since I upgraded from 2.6.9+hack, which works beautifully. 1) With 2.6.11+hack, compiled for the Pentium-M, the system freezes at or soon after I close the LCD screen. Out of curiosity, I tried the FN - [F4] combination, which I believe should try to flip the video output to the external monitor port (I have nothing plugged in there). This immediately made the machine starting counting memory, and it turns out it had completely erased the BIOS settings to defaults and set the date back to Jan 4 of this year! 2) With 2.6.10-1.770_FC2 I totally froze the system when I tried to 'ifup eth0'. eth0 is BCM5705M (b44 driver) 3) When it freezes, the machine gets really hot, and the fan does not increase in speed like it normally does. I am not sure if this means anything, but I thought I'd share it. For now, I'm back at 2.6.9+hack, but I'm willing to try the newer kernels if someone has a suggestion or needs more debugging. Install is: FC2, mostly up-to-date when I was having these problems, fully up-to-date now. cpu: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.50GHz stepping: 6 cpu MHz : 1495.769 cache size : 2048 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2 bogomips: 2965.50 lspci of this system: 00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) 00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02) 00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02) 00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) 00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 01) 00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01) 00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 01) 01:04.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) 01:06.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller 01:06.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller 01:06.3 Unknown mass storage controller: Texas Instruments PCI7420 Flash Media Controller 01:0d.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) 01:0e.0 Ethernet controller: Broadcom Corporation BCM5705M 10/100/1000Base T (rev 02) -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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: Kernel SCM saga..
On Wed, 06 Apr 2005 23:39:11 +0400, Paul P Komkoff Jr wrote: > http://bazaar-ng.org/ I'd like bazaar-ng to be considered too. It is not ready for adoption yet, but I am working (more than) full time on it and hope to have it be usable in a couple of months. bazaar-ng is trying to integrate a lot of the work done in other systems to make something that is simple to use but also fast and powerful enough to handle large projects. The operations that are already done are pretty fast: ~60s to import a kernel tree, ~10s to import a new revision from a patch. Please check it out and do pester me with any suggestions about whatever you think it needs to suit your work. -- Martin - 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][RFC] disable built-in modules V2
Hi,
> -#define module_init(x) __initcall(x);
> +#define module_init(x) __initcall(x); __module_init_disable(x);
It would be better if there is brackets around them... like
#define module_init(x) { __initcall(x); __module_init_disable(x); }
then we know it wont break some code like
if (..)
module_init(x);
thanks.
-
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: Kernel SCM saga..
On Wed, 6 Apr 2005, Jon Smirl wrote: > There is a large difference in the behavior of corporations with huge > source bases and college students with no money. The corporations will > pay to have someone responsible for ensuring that the product works. Or they will merge with some other entity on the whim of some executive and the corporation then decides to kill the product for good without releasing the source leaving you out in the cold. - 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 5/6] freepgt2: arch FIRST_USER_ADDRESS 0
Replace misleading definition of FIRST_USER_PGD_NR 0 by definition of FIRST_USER_ADDRESS 0 in all the MMU architectures beyond arm and arm26. Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> --- include/asm-alpha/pgtable.h |2 +- include/asm-cris/pgtable.h |2 +- include/asm-frv/pgtable.h |2 +- include/asm-i386/pgtable.h |2 +- include/asm-ia64/pgtable.h |2 +- include/asm-m32r/pgtable.h |2 +- include/asm-m68k/pgtable.h |2 +- include/asm-mips/pgtable-32.h |2 +- include/asm-mips/pgtable-64.h |2 +- include/asm-parisc/pgtable.h|2 +- include/asm-ppc/pgtable.h |2 +- include/asm-ppc64/pgtable.h |2 +- include/asm-s390/pgtable.h |4 ++-- include/asm-sh/pgtable.h|2 +- include/asm-sh64/pgtable.h |2 +- include/asm-sparc/pgtable.h |2 +- include/asm-sparc64/pgtable.h |2 +- include/asm-um/pgtable-2level.h |2 +- include/asm-um/pgtable-3level.h |2 +- include/asm-x86_64/pgtable.h|2 +- 20 files changed, 21 insertions(+), 21 deletions(-) --- 2.6.12-rc2-mm1/include/asm-alpha/pgtable.h 2005-04-05 15:20:54.0 +0100 +++ linux/include/asm-alpha/pgtable.h 2005-04-05 18:59:00.0 +0100 @@ -42,7 +42,7 @@ #define PTRS_PER_PMD (1UL << (PAGE_SHIFT-3)) #define PTRS_PER_PGD (1UL << (PAGE_SHIFT-3)) #define USER_PTRS_PER_PGD (TASK_SIZE / PGDIR_SIZE) -#define FIRST_USER_PGD_NR 0 +#define FIRST_USER_ADDRESS 0 /* Number of pointers that fit on a page: this will go away. */ #define PTRS_PER_PAGE (1UL << (PAGE_SHIFT-3)) --- 2.6.12-rc2-mm1/include/asm-cris/pgtable.h 2005-04-05 15:20:55.0 +0100 +++ linux/include/asm-cris/pgtable.h2005-04-05 18:59:00.0 +0100 @@ -76,7 +76,7 @@ extern void paging_init(void); */ #define USER_PTRS_PER_PGD (TASK_SIZE/PGDIR_SIZE) -#define FIRST_USER_PGD_NR 0 +#define FIRST_USER_ADDRESS 0 /* zero page used for uninitialized stuff */ #ifndef __ASSEMBLY__ --- 2.6.12-rc2-mm1/include/asm-frv/pgtable.h2005-04-05 15:20:55.0 +0100 +++ linux/include/asm-frv/pgtable.h 2005-04-05 18:59:00.0 +0100 @@ -141,7 +141,7 @@ extern unsigned long empty_zero_page; #define PTRS_PER_PTE 4096 #define USER_PGDS_IN_LAST_PML4 (TASK_SIZE / PGDIR_SIZE) -#define FIRST_USER_PGD_NR 0 +#define FIRST_USER_ADDRESS 0 #define USER_PGD_PTRS (PAGE_OFFSET >> PGDIR_SHIFT) #define KERNEL_PGD_PTRS(PTRS_PER_PGD - USER_PGD_PTRS) --- 2.6.12-rc2-mm1/include/asm-i386/pgtable.h 2005-04-05 15:20:55.0 +0100 +++ linux/include/asm-i386/pgtable.h2005-04-05 18:59:00.0 +0100 @@ -60,7 +60,7 @@ void paging_init(void); #define PGDIR_MASK (~(PGDIR_SIZE-1)) #define USER_PTRS_PER_PGD (TASK_SIZE/PGDIR_SIZE) -#define FIRST_USER_PGD_NR 0 +#define FIRST_USER_ADDRESS 0 #define USER_PGD_PTRS (PAGE_OFFSET >> PGDIR_SHIFT) #define KERNEL_PGD_PTRS (PTRS_PER_PGD-USER_PGD_PTRS) --- 2.6.12-rc2-mm1/include/asm-ia64/pgtable.h 2005-04-05 15:22:58.0 +0100 +++ linux/include/asm-ia64/pgtable.h2005-04-05 18:59:00.0 +0100 @@ -93,7 +93,7 @@ #define PGDIR_MASK (~(PGDIR_SIZE-1)) #define PTRS_PER_PGD (1UL << (PAGE_SHIFT-3)) #define USER_PTRS_PER_PGD (5*PTRS_PER_PGD/8) /* regions 0-4 are user regions */ -#define FIRST_USER_PGD_NR 0 +#define FIRST_USER_ADDRESS 0 /* * Definitions for second level: --- 2.6.12-rc2-mm1/include/asm-m32r/pgtable.h 2005-04-05 15:20:56.0 +0100 +++ linux/include/asm-m32r/pgtable.h2005-04-05 18:59:00.0 +0100 @@ -51,7 +51,7 @@ extern unsigned long empty_zero_page[102 #define PGDIR_MASK (~(PGDIR_SIZE - 1)) #define USER_PTRS_PER_PGD (TASK_SIZE / PGDIR_SIZE) -#define FIRST_USER_PGD_NR 0 +#define FIRST_USER_ADDRESS 0 #ifndef __ASSEMBLY__ /* Just any arbitrary offset to the start of the vmalloc VM area: the --- 2.6.12-rc2-mm1/include/asm-m68k/pgtable.h 2005-04-05 15:20:56.0 +0100 +++ linux/include/asm-m68k/pgtable.h2005-04-05 18:59:00.0 +0100 @@ -61,7 +61,7 @@ #define PTRS_PER_PGD 128 #endif #define USER_PTRS_PER_PGD (TASK_SIZE/PGDIR_SIZE) -#define FIRST_USER_PGD_NR 0 +#define FIRST_USER_ADDRESS 0 /* Virtual address region for use by kernel_map() */ #ifdef CONFIG_SUN3 --- 2.6.12-rc2-mm1/include/asm-mips/pgtable-32.h2005-03-02 07:38:57.0 + +++ linux/include/asm-mips/pgtable-32.h 2005-04-05 18:59:00.0 +0100 @@ -74,7 +74,7 @@ extern int add_temporary_entry(unsigned #define PTRS_PER_PTE ((PAGE_SIZE << PTE_ORDER) / sizeof(pte_t)) #define USER_PTRS_PER_PGD (0x8000UL/PGDIR_SIZE) -#define FIRST_USER_PGD_NR 0 +#define FIRST_USER_ADDRESS 0 #define VMALLOC_START KSEG2 --- 2.6.12-rc2-mm1/include/asm-mips/pgtable-64.h2004-12-24 21:36:18.0 + +++
[PATCH 6/6] freepgt2: remove FIRST_USER_ADDRESS hack
Once all the MMU architectures define FIRST_USER_ADDRESS, remove hack from mmap.c which derived it from FIRST_USER_PGD_NR. Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> --- mm/mmap.c |5 - 1 files changed, 5 deletions(-) --- 2.6.12-rc2-mm1+/mm/mmap.c 2005-04-05 18:59:01.0 +0100 +++ linux/mm/mmap.c 2005-04-07 00:32:43.0 +0100 @@ -1608,11 +1608,6 @@ static void unmap_vma_list(struct mm_str validate_mm(mm); } -#ifndef FIRST_USER_ADDRESS /* temporary hack */ -#define THIS_IS_ARMFIRST_USER_PGD_NR -#define FIRST_USER_ADDRESS (THIS_IS_ARM * PAGE_SIZE) -#endif - /* * Get rid of page table information in the indicated region. * - 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 4/6] freepgt2: arm26 FIRST_USER_ADDRESS PAGE_SIZE
ARM26 define FIRST_USER_ADDRESS as PAGE_SIZE (beyond the machine vectors when they are mapped low), and use that definition in place of locally defined MIN_MAP_ADDR. Previously, ARM26 permitted user mappings at 0 if the machine vectors were mapped high; but that's inconsistent with ARM, and FIRST_USER_ADDRESS would then have to be determined at runtime. Let's fix it at PAGE_SIZE throughout the architecture. Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> --- arch/arm26/kernel/sys_arm.c |9 - include/asm-arm26/pgtable.h |7 +++ 2 files changed, 11 insertions(+), 5 deletions(-) --- 2.6.12-rc2-mm1/arch/arm26/kernel/sys_arm.c 2005-03-02 07:38:58.0 + +++ linux/arch/arm26/kernel/sys_arm.c 2005-04-05 18:59:00.0 +0100 @@ -64,10 +64,10 @@ inline long do_mmap2( flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE); /* -* If we are doing a fixed mapping, and address < PAGE_SIZE, +* If we are doing a fixed mapping, and address < FIRST_USER_ADDRESS, * then deny it. */ - if (flags & MAP_FIXED && addr < PAGE_SIZE && vectors_base() == 0) + if (flags & MAP_FIXED && addr < FIRST_USER_ADDRESS) goto out; error = -EBADF; @@ -121,11 +121,10 @@ sys_arm_mremap(unsigned long addr, unsig unsigned long ret = -EINVAL; /* -* If we are doing a fixed mapping, and address < PAGE_SIZE, +* If we are doing a fixed mapping, and address < FIRST_USER_ADDRESS, * then deny it. */ - if (flags & MREMAP_FIXED && new_addr < PAGE_SIZE && - vectors_base() == 0) + if (flags & MREMAP_FIXED && new_addr < FIRST_USER_ADDRESS) goto out; down_write(>mm->mmap_sem); --- 2.6.12-rc2-mm1/include/asm-arm26/pgtable.h 2005-04-05 15:20:55.0 +0100 +++ linux/include/asm-arm26/pgtable.h 2005-04-05 18:59:00.0 +0100 @@ -62,6 +62,13 @@ #define PTRS_PER_PMD1 #define PTRS_PER_PTE32 +/* + * This is the lowest virtual address we can permit any user space + * mapping to be mapped at. This is particularly important for + * non-high vector CPUs. + */ +#define FIRST_USER_ADDRESS PAGE_SIZE + #define FIRST_USER_PGD_NR 1 #define USER_PTRS_PER_PGD ((TASK_SIZE/PGD_SIZE) - FIRST_USER_PGD_NR) - 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-usb-devel] USB glitches after suspend on ppc
On Wednesday 06 April 2005 4:50 pm, Benjamin Herrenschmidt wrote: > On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote: > > On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote: > > > > > > > Thanks for the testing update. I'm glad to know that there seems to > > > > be only one (minor) glitch that's PPC-specific! > > > > > > Which is just an off-the-shelves NEC EHCI chip. > > > > The wakeup-after-suspend hasn't been reported by anyone else. > > Looks like the root hub is set for triggering wakeups on connect, isn't > that just a setting in there ? The old Apple ASIC had a bit somewhere to > control that, but I don't know about the NEC The NEC chip uses PME# for PCI wakeup, which pci_enable_wake(..., 0) is supposed to have disabled. If it's not disabling PME#, that's a bug in the PCI infrastructure on that platform. If some other signal is causing a wakeup, that's a different platform-specific issue. :) - 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 3/6] freepgt2: arm FIRST_USER_ADDRESS PAGE_SIZE
ARM define FIRST_USER_ADDRESS as PAGE_SIZE (beyond the machine vectors
when they are mapped low), and use that definition in place of locally
defined MIN_MAP_ADDR.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
---
arch/arm/kernel/sys_arm.c | 11 ++-
include/asm-arm/pgtable.h |7 +++
2 files changed, 9 insertions(+), 9 deletions(-)
--- 2.6.12-rc2-mm1/arch/arm/kernel/sys_arm.c2005-04-05 15:20:23.0
+0100
+++ linux/arch/arm/kernel/sys_arm.c 2005-04-05 18:59:00.0 +0100
@@ -51,13 +51,6 @@ asmlinkage int sys_pipe(unsigned long __
return error;
}
-/*
- * This is the lowest virtual address we can permit any user space
- * mapping to be mapped at. This is particularly important for
- * non-high vector CPUs.
- */
-#define MIN_MAP_ADDR (PAGE_SIZE)
-
/* common code for old and new mmaps */
inline long do_mmap2(
unsigned long addr, unsigned long len,
@@ -69,7 +62,7 @@ inline long do_mmap2(
flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE);
- if (flags & MAP_FIXED && addr < MIN_MAP_ADDR)
+ if (flags & MAP_FIXED && addr < FIRST_USER_ADDRESS)
goto out;
error = -EBADF;
@@ -122,7 +115,7 @@ sys_arm_mremap(unsigned long addr, unsig
{
unsigned long ret = -EINVAL;
- if (flags & MREMAP_FIXED && new_addr < MIN_MAP_ADDR)
+ if (flags & MREMAP_FIXED && new_addr < FIRST_USER_ADDRESS)
goto out;
down_write(>mm->mmap_sem);
--- 2.6.12-rc2-mm1/include/asm-arm/pgtable.h2005-04-05 15:20:55.0
+0100
+++ linux/include/asm-arm/pgtable.h 2005-04-05 18:59:00.0 +0100
@@ -102,6 +102,13 @@ extern void __pgd_error(const char *file
#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
#define PGDIR_MASK (~(PGDIR_SIZE-1))
+/*
+ * This is the lowest virtual address we can permit any user space
+ * mapping to be mapped at. This is particularly important for
+ * non-high vector CPUs.
+ */
+#define FIRST_USER_ADDRESS PAGE_SIZE
+
#define FIRST_USER_PGD_NR 1
#define USER_PTRS_PER_PGD ((TASK_SIZE/PGDIR_SIZE) - FIRST_USER_PGD_NR)
-
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] freepgt2: sys_mincore ignore FIRST_USER_PGD_NR
Remove use of FIRST_USER_PGD_NR from sys_mincore: it's inconsistent (no other syscall refers to it), unnecessary (sys_mincore loops over vmas further down) and incorrect (misses user addresses in ARM's first pgd). Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> --- mm/mincore.c |3 --- 1 files changed, 3 deletions(-) --- 2.6.12-rc2-mm1/mm/mincore.c 2005-04-05 15:21:02.0 +0100 +++ linux/mm/mincore.c 2005-04-05 18:59:01.0 +0100 @@ -118,9 +118,6 @@ asmlinkage long sys_mincore(unsigned lon if (start & ~PAGE_CACHE_MASK) goto einval; - if (start < FIRST_USER_PGD_NR * PGDIR_SIZE) - goto enomem; - limit = TASK_SIZE; if (start >= limit) goto enomem; - 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/6] freepgt2: free_pgtables from FIRST_USER_ADDRESS
The patches to free_pgtables by vma left problems on any architectures which leave some user address page table entries unencapsulated by vma. Andi has fixed the 32-bit vDSO on x86_64 to use a vma. Now fix arm (and arm26), whose first PAGE_SIZE is reserved (perhaps) for machine vectors. Our calls to free_pgtables must not touch that area, and exit_mmap's BUG_ON(nr_ptes) must allow that arm's get_pgd_slow may (or may not) have allocated an extra page table, which its free_pgd_slow would free later. FIRST_USER_PGD_NR has misled me and others: until all the arches define FIRST_USER_ADDRESS instead, a hack in mmap.c to derive one from t'other. This patch fixes the bugs, the remaining patches just clean it up. Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> --- mm/mmap.c | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) --- 2.6.12-rc2-mm1/mm/mmap.c2005-04-05 15:23:00.0 +0100 +++ linux/mm/mmap.c 2005-04-05 18:59:01.0 +0100 @@ -1608,6 +1608,11 @@ static void unmap_vma_list(struct mm_str validate_mm(mm); } +#ifndef FIRST_USER_ADDRESS /* temporary hack */ +#define THIS_IS_ARMFIRST_USER_PGD_NR +#define FIRST_USER_ADDRESS (THIS_IS_ARM * PAGE_SIZE) +#endif + /* * Get rid of page table information in the indicated region. * @@ -1626,7 +1631,7 @@ static void unmap_region(struct mm_struc tlb = tlb_gather_mmu(mm, 0); unmap_vmas(, mm, vma, start, end, _accounted, NULL); vm_unacct_memory(nr_accounted); - free_pgtables(, vma, prev? prev->vm_end: 0, + free_pgtables(, vma, prev? prev->vm_end: FIRST_USER_ADDRESS, next? next->vm_start: 0); tlb_finish_mmu(tlb, start, end); spin_unlock(>page_table_lock); @@ -1906,7 +1911,7 @@ void exit_mmap(struct mm_struct *mm) /* Use -1 here to ensure all VMAs in the mm are unmapped */ end = unmap_vmas(, mm, vma, 0, -1, _accounted, NULL); vm_unacct_memory(nr_accounted); - free_pgtables(, vma, 0, 0); + free_pgtables(, vma, FIRST_USER_ADDRESS, 0); tlb_finish_mmu(tlb, 0, end); mm->mmap = mm->mmap_cache = NULL; @@ -1927,7 +1932,7 @@ void exit_mmap(struct mm_struct *mm) vma = next; } - BUG_ON(mm->nr_ptes);/* This is just debugging */ + BUG_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT); } /* Insert vm structure into process list sorted by address - 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] April Release of LTP now Available
Paul Mackerras wrote:
if (__sc_err & 0x1000) \
{ \
errno = __sc_ret; \
__sc_ret = -1; \
} \
If you're messing with that code anyways, any chance of changing the
assignment to "__sc_ret = -1UL;", since __sc_ret is of type unsigned long?
Chris
-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Llu, 2005-04-04 at 21:47, Jeff Garzik wrote: > Bluntly, Debian is being a pain in the ass ;-) > > There will always be non-free firmware to deal with, for key hardware. Firmware being seperate does make a lot of sense. It isn't going away but it doesn't generally belong in kernel now we have initrd and firmware loaders. Alan - 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] April Release of LTP now Available
Andrew Morton writes:
> Marty Ridgeway <[EMAIL PROTECTED]> wrote:
> >
> > The April release of LTP is now on SourceForge.
> >
> > LTP-20050405
>
> It seems to have an x86ism in it which causes the compile to fail on ppc64:
Looks to me like gcc is objecting to our (ppc64's) _syscall2
definition; Alan Modra (cc'd) can probably say what we're doing wrong.
> socketcall01.c: In function `socketcall':
> socketcall01.c:80: error: asm-specifier for variable `__sc_4' conflicts with
> asm clobber list
>
>
>
>
> #ifndef _syscall2
> #include
> #endif
>
> #include "test.h"
> #include "usctest.h"
>
> char *TCID = "socketcall01"; /* Test program
> identifier.*/
> #ifdef __NR_socketcall
>
> _syscall2(int ,socketcall ,int ,call, unsigned long *, args);
Here is the definition of _syscall2 (for Alan):
#define __syscall_nr(nr, type, name, args...) \
unsigned long __sc_ret, __sc_err; \
{ \
register unsigned long __sc_0 __asm__ ("r0"); \
register unsigned long __sc_3 __asm__ ("r3"); \
register unsigned long __sc_4 __asm__ ("r4"); \
register unsigned long __sc_5 __asm__ ("r5"); \
register unsigned long __sc_6 __asm__ ("r6"); \
register unsigned long __sc_7 __asm__ ("r7"); \
register unsigned long __sc_8 __asm__ ("r8"); \
\
__sc_loadargs_##nr(name, args); \
__asm__ __volatile__\
("sc \n\t"\
"mfcr %0 "\
: "=" (__sc_0), \
"=" (__sc_3), "=" (__sc_4), \
"=" (__sc_5), "=" (__sc_6), \
"=" (__sc_7), "=" (__sc_8) \
: __sc_asm_input_##nr \
: "cr0", "ctr", "memory", \
"r9", "r10","r11", "r12"); \
__sc_ret = __sc_3; \
__sc_err = __sc_0; \
} \
if (__sc_err & 0x1000) \
{ \
errno = __sc_ret; \
__sc_ret = -1; \
} \
return (type) __sc_ret
#define __sc_loadargs_0(name, dummy...) \
__sc_0 = __NR_##name
#define __sc_loadargs_1(name, arg1) \
__sc_loadargs_0(name); \
__sc_3 = (unsigned long) (arg1)
#define __sc_loadargs_2(name, arg1, arg2) \
__sc_loadargs_1(name, arg1);\
__sc_4 = (unsigned long) (arg2)
#define __sc_loadargs_3(name, arg1, arg2, arg3) \
__sc_loadargs_2(name, arg1, arg2); \
__sc_5 = (unsigned long) (arg3)
#define __sc_loadargs_4(name, arg1, arg2, arg3, arg4) \
__sc_loadargs_3(name, arg1, arg2, arg3);\
__sc_6 = (unsigned long) (arg4)
#define __sc_loadargs_5(name, arg1, arg2, arg3, arg4, arg5) \
__sc_loadargs_4(name, arg1, arg2, arg3, arg4); \
__sc_7 = (unsigned long) (arg5)
#define __sc_loadargs_6(name, arg1, arg2, arg3, arg4, arg5, arg6) \
__sc_loadargs_5(name, arg1, arg2, arg3, arg4, arg5);\
__sc_8 = (unsigned long) (arg6)
#define __sc_asm_input_0 "0" (__sc_0)
#define __sc_asm_input_1 __sc_asm_input_0, "1" (__sc_3)
#define __sc_asm_input_2 __sc_asm_input_1, "2" (__sc_4)
#define __sc_asm_input_3 __sc_asm_input_2, "3" (__sc_5)
#define __sc_asm_input_4 __sc_asm_input_3, "4" (__sc_6)
#define __sc_asm_input_5 __sc_asm_input_4, "5" (__sc_7)
#define __sc_asm_input_6 __sc_asm_input_5, "6" (__sc_8)
#define _syscall0(type,name)\
type name(void) \
{ \
__syscall_nr(0, type, name);\
}
#define
Re: 2.6.12-rc2-mm1
On Tuesday 05 April 2005 03:05, Andrew Morton wrote: > - x86 NMI handling seems to be bust in 2.6.12-rc2. Try using > `nmi_watchdog=0' if you experience weird crashes. > > - The possible kernel-timer related hangs might possibly be fixed. We > haven't heard yet. > > - Nobody said anything about the PM resume and DRI behaviour in > 2.6.12-rc1-mm4. So it's all perfect now? > > - Various fixes and updates. Nothing earth-shattering. This refuses to boot here. It dies when assigning the EHCI driver. The mb is an MSI-7030 K8N Neo Platinium based on a nForce 3 250Gb Chipset (x86_64). I`ve been on vacation - the last kernel tried was 11-mm3 which booted fine but refuses to use all the usb ports supplied by the system (two work, three do not all using low speed). Any ideas what might be happening? Ed Tomlinson - 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/4] create mm/Kconfig for arch-independent memory options
Hi, On Wed, 6 Apr 2005, Dave Hansen wrote: > > Why is this choice needed at all? Why would one choose SPARSEMEM over > > DISCONTIGMEM? > > For now, it's only so people can test either one, and we don't have to > try to toss DICONTIGMEM out of the kernel in fell swoop. When the > memory hotplug options are enabled, the DISCONTIG option goes away, and > SPARSEMEM is selected as the only option. > > I hope to, in the future, make the options more like this: > > config MEMORY_HOTPLUG... > config NUMA... > > config DISCONTIGMEM > depends on NUMA && !MEMORY_HOTPLUG > > config SPARSEMEM > depends on MEMORY_HOTPLUG || OTHER_ARCH_THING > > config FLATMEM > depends on !DISCONTIGMEM && !SPARSEMEM I was hoping for this too, in the meantime can't you simply make it a suboption of DISCONTIGMEM? So an extra option is only visible when it's enabled and most people can ignore it completely by just disabling a single option. > > Help texts such as "If unsure, choose " make > > the complete config option pretty useless. > > They don't make it useless, they just guide a clueless user to the right > place, without them having to think about it at all. Those of us that > need to test the various configurations are quite sure of what we're > doing, and can ignore the messages. :) > > I'm not opposed to creating some better help text for those things, I'm > just not sure that we really need it, or that it will help end users get > to the right place. I guess more explanation never hurt anyone. Some basic explanation with a link for more information can't hurt. bye, Roman - 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.4.30: pwc pwc_isoc_handler() called with status -84
On Tue, 5 Apr 2005 10:55:52 -0300 Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > CCing Pete. > > On Mon, Apr 04, 2005 at 08:59:57PM +0200, Gabor Z. Papp wrote: > > It was working fine with 2.4.29 and earlier kernels, often with > > 100-150 days uptime. > > > > As I upgraded to 2.4.30-rc kernels, started getting such error in my > > kernel log: > > > > pwc Too many ISOC errors, bailing out. > > pwc pwc_isoc_handler() called with status -84 [CRC/Timeout (could be > > anything)]. There is no other way but to start splitting patches and diff-ing. We can narrow this down a little by looking at what _might_ be involved. Is this device driven by EHCI? A snapshot of /proc/bus/usb/devices would be useful (BTW, Gabor, please do it on both 2.4.28 and 2.4.30-rc). Thanks, -- Pete - 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/4] create mm/Kconfig for arch-independent memory options
On Thu, 2005-04-07 at 01:40 +0200, Roman Zippel wrote: > On Wed, 6 Apr 2005, Dave Hansen wrote: > > On Wed, 2005-04-06 at 22:58 +0200, Roman Zippel wrote: > > > Dave Hansen wrote: > > > > --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0 > > > > -0700 > > > > +++ memhotplug-dave/mm/Kconfig 2005-04-04 10:15:23.0 -0700 > > > > @@ -0,0 +1,25 @@ > > > > +choice > > > > + prompt "Memory model" > > > > + default FLATMEM > > > > + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT > > > > + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT > > > > > > Does this really have to be a user visible option and can't it be > > > derived from other values? The help text entries are really no help at > > > all. > > > > I hope that this selection will replace the current DISCONTIGMEM prompts > > in the individual architectures. That way, you won't get a net increase > > in the number of prompts. > > Why is this choice needed at all? Why would one choose SPARSEMEM over > DISCONTIGMEM? For now, it's only so people can test either one, and we don't have to try to toss DICONTIGMEM out of the kernel in fell swoop. When the memory hotplug options are enabled, the DISCONTIG option goes away, and SPARSEMEM is selected as the only option. I hope to, in the future, make the options more like this: config MEMORY_HOTPLUG... config NUMA... config DISCONTIGMEM depends on NUMA && !MEMORY_HOTPLUG config SPARSEMEM depends on MEMORY_HOTPLUG || OTHER_ARCH_THING config FLATMEM depends on !DISCONTIGMEM && !SPARSEMEM So, if they enable NUMA, they get DISCONTIGMEM automatically. If they enable MEMORY_HOTPLUG on top of that, they automatically get SPARSEMEM instead. All of the complex "pick your memory model" stuff goes away, and you just select features. However, I think the current situation is a reasonable intermediate step, as we need to be able to switch back and forth for now. > Help texts such as "If unsure, choose " make > the complete config option pretty useless. They don't make it useless, they just guide a clueless user to the right place, without them having to think about it at all. Those of us that need to test the various configurations are quite sure of what we're doing, and can ignore the messages. :) I'm not opposed to creating some better help text for those things, I'm just not sure that we really need it, or that it will help end users get to the right place. I guess more explanation never hurt anyone. -- 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: [linux-usb-devel] USB glitches after suspend on ppc
On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote: > On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote: > > > > > Thanks for the testing update. I'm glad to know that there seems to > > > be only one (minor) glitch that's PPC-specific! > > > > Which is just an off-the-shelves NEC EHCI chip. > > The wakeup-after-suspend hasn't been reported by anyone else. Looks like the root hub is set for triggering wakeups on connect, isn't that just a setting in there ? The old Apple ASIC had a bit somewhere to control that, but I don't know about the NEC Ben. - 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] CON_CONSDEV bit not set correctly on last console
In article <[EMAIL PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]> wrote: >Greg Edwards <[EMAIL PROTECTED]> wrote: >> >> According to include/linux/console.h, CON_CONSDEV flag should be set on >> the last console specified on the boot command line: >> >> 86 #define CON_PRINTBUFFER (1) >> 87 #define CON_CONSDEV (2) /* Last on the command line */ >> 88 #define CON_ENABLED (4) >> 89 #define CON_BOOT(8) >> >> This does not currently happen if there is more than one console specified >> on the boot commandline. Instead, it gets set on the first console on the >> command line. This can cause problems for things like kdb that look for >> the CON_CONSDEV flag to see if the console is valid. >> >> Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next >> preferred console at unregister time if the console being unregistered >> currently has that bit set. >> >> Example (from sn2 ia64): >> >> elilo vmlinuz root= console=ttyS0 console=ttySG0 >> >> in this case, the flags on ttySG console struct will be 0x4 (should be >> 0x6). >> >> Attached patch against bk fixes both issues for the cases I looked at. It >> uses selected_console (which gets incremented for each console specified >> on the command line) as the indicator of which console to set CON_CONSDEV >> on. When adding the console to the list, if the previous one had >> CON_CONSDEV set, it masks it out. Tested on ia64 and x86. > >The `console=a console=b' behaviour seem basically random to me :(. And it >gets re-randomised on a regular basis. Well, on the other hand the last registered console is the one that connects to /dev/console and that has never changed afaik (and it shouldn't, many setups rely on it). Mike. - 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/4] create mm/Kconfig for arch-independent memory options
Hi, On Wed, 6 Apr 2005, Dave Hansen wrote: > On Wed, 2005-04-06 at 22:58 +0200, Roman Zippel wrote: > > Dave Hansen wrote: > > > --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0 > > > -0700 > > > +++ memhotplug-dave/mm/Kconfig2005-04-04 10:15:23.0 -0700 > > > @@ -0,0 +1,25 @@ > > > +choice > > > + prompt "Memory model" > > > + default FLATMEM > > > + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT > > > + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT > > > > Does this really have to be a user visible option and can't it be > > derived from other values? The help text entries are really no help at all. > > I hope that this selection will replace the current DISCONTIGMEM prompts > in the individual architectures. That way, you won't get a net increase > in the number of prompts. Why is this choice needed at all? Why would one choose SPARSEMEM over DISCONTIGMEM? Help texts such as "If unsure, choose " make the complete config option pretty useless. bye, Roman - 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-usb-devel] USB glitches after suspend on ppc
On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote: > > > Thanks for the testing update. I'm glad to know that there seems to > > be only one (minor) glitch that's PPC-specific! > > Which is just an off-the-shelves NEC EHCI chip. The wakeup-after-suspend hasn't been reported by anyone else. - 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.12-rc2
On Wed, Apr 06, 2005 at 05:20:52PM -0600, Bob Gill wrote: > OK. So far so good. I can get 2.6.12-rc2 to run fine if: > 1. I do not in any way attempt to *ahem* overclock the box. > --if I do, I get really ugly race errors flying around from just about > everywhere (pick a device at random, have it trip, and the scheduler > tripping right behind it). "Doctor it hurts when I do this.." > 2. I do not attempt in any way to run any sort of Nvidia (non-GPL) > driver. Totally unsurprising. They'll need serious brain surgery to work with the multi-gart support. I'm amazed they even compiled for you. 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: Kernel SCM saga..
On Apr 6, 2005 4:42 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote: > as a number of people are already aware (and in some > cases have been aware over the last several weeks), we've > been trying to work out a conflict over BK usage over the last > month or two (and it feels like longer ;). That hasn't been > working out, and as a result, the kernel team is looking at > alternatives. What about the 64K changeset limitation in current releases? Did I miss something (like the fixes promised) or is there going to be another interim release before the end of support? Jon. P.S. Apologies if this already got addressed. - 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.12-rc2
OK. So far so good. I can get 2.6.12-rc2 to run fine if: 1. I do not in any way attempt to *ahem* overclock the box. --if I do, I get really ugly race errors flying around from just about everywhere (pick a device at random, have it trip, and the scheduler tripping right behind it). 2. I do not attempt in any way to run any sort of Nvidia (non-GPL) driver. It fights with SBP2 (in a lot of different ways, first the drivers want to kill off Firewire drives (one detected, the other not, then on next boot, the reverse...), and also, when using GLX apps (and trying to write to an SBP2 connected device, they clash (and fight and the kernel doesn't die but gets bogged in errors...) and with the notes above, as I say, so far, so good. I am attempting to hammer away at every device I have on the box (scanner, printer, video (only GPL Nvidia), audio, cd, dvd, tv tuner etc.) so far, so good. Bob -- Bob Gill <[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: bdflush/rpciod high CPU utilization, profile does not make sense
On Wed, Apr 06, 2005 at 06:01:23PM +0200, Jakob Oestergaard wrote: > > Problem; during simple tests such as a 'cp largefile0 largefile1' on the > client (under the mountpoint from the NFS server), the client becomes > extremely laggy, NFS writes are slow, and I see very high CPU > utilization by bdflush and rpciod. > > For example, writing a single 8G file with dd will give me about > 20MB/sec (I get 60+ MB/sec locally on the server), and the client rarely > drops below 40% system CPU utilization. How large is the client's RAM? What does the following command report before and during the write? egrep 'nfs_page|nfs_write_data' /proc/slabinfo Greg. -- Greg Banks, R Software Engineer, SGI Australian Software Group. I don't speak for SGI. - 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-usb-devel] USB glitches after suspend on ppc
> Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually > disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if > not, then it's odd that the system went back to sleep!) Do you think > that might be related to those calls manipulating the Apple ASICs being > in the OHCI layer rather than up nearer the generic PCI glue? (I still > think they don't belong in USB code -- ohci or usbcore -- at all. If > the platform-specific PCI hooks don't suffice, they need fixing.) There are no platform hooks in the right place for now afaik. Anyway, I think Colin's controller is an OHCI/EHCI NEC chip, so not an Apple ASIC, it's not doing anything in those calls. > Thanks for the testing update. I'm glad to know that there seems to > be only one (minor) glitch that's PPC-specific! Which is just an off-the-shelves NEC EHCI chip. > > - once out of two resumes, resume leaves the ports unpowered; so I still > > need my usb-ehci-power.patch that re-powers ports unconditionnaly. > > OK, I just posted the patch cleaning up EHCI port power switching; > that should remove the need for that separate patch. (As well as > fixing some minor annoyances.) > > - Dave > > -- Benjamin Herrenschmidt <[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: [PATCH] CON_CONSDEV bit not set correctly on last console
Greg Edwards <[EMAIL PROTECTED]> wrote: > > According to include/linux/console.h, CON_CONSDEV flag should be set on > the last console specified on the boot command line: > > 86 #define CON_PRINTBUFFER (1) > 87 #define CON_CONSDEV (2) /* Last on the command line */ > 88 #define CON_ENABLED (4) > 89 #define CON_BOOT(8) > > This does not currently happen if there is more than one console specified > on the boot commandline. Instead, it gets set on the first console on the > command line. This can cause problems for things like kdb that look for > the CON_CONSDEV flag to see if the console is valid. > > Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next > preferred console at unregister time if the console being unregistered > currently has that bit set. > > Example (from sn2 ia64): > > elilo vmlinuz root= console=ttyS0 console=ttySG0 > > in this case, the flags on ttySG console struct will be 0x4 (should be > 0x6). > > Attached patch against bk fixes both issues for the cases I looked at. It > uses selected_console (which gets incremented for each console specified > on the command line) as the indicator of which console to set CON_CONSDEV > on. When adding the console to the list, if the previous one had > CON_CONSDEV set, it masks it out. Tested on ia64 and x86. The `console=a console=b' behaviour seem basically random to me :(. And it gets re-randomised on a regular basis. I wonder if we should leave the existing behaviour alone (continue to set CON_CONSDEV on the first console) and just change the documentation? That'll minimise the disruption which we cause. - 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: [03/08] fix ia64 syscall auditing
Ryan Anderson <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 05, 2005 at 01:49:18PM -0700, Greg KH wrote: > > On Tue, 2005-04-05 at 13:27 -0700, David Mosberger wrote: > > > > On Tue, 5 Apr 2005 09:46:48 -0700, Greg KH <[EMAIL PROTECTED]> said: > > > > > > Greg> -stable review patch. If anyone has any objections, please > > > Greg> let us know. > > > > > > Nitpick: the patch introduces trailing whitespace. > > > > Sorry about that, I've removed it from the patch now. > > > > > Why doesn't everybody use emacs and enable show-trailing-whitespace? ;-) > > > > Because some of us use vim and ":set list" to see it, when we remember > > to... :) > > Try adding this to your .vimrc: > > highlight WhitespaceEOL ctermbg=red guibg=red > match WhitespaceEOL /\s\+$/ > > Then you'll have to resist the urge to fix whitespace issues instead of > not seeing them at all. > Yeah, that's a risk. But gratuitous trailing whitespace changes shouldn't cause a lot of downstream problems due to `patch -l'. What I do is to ensure that we never _add_ trailing whitespace. So anything which matches ^+.*[tab or space]$ gets trimmed. My theory is that after 10 years of this, all the trailing whitespace will be gone. Problem is, I also see the hundreds of lines of code in the bk patches which add trailing whitespace :( Larry sent me a little bk script which would spam the user if they tried to commit something which adds trailing whitespace, but maybe that's a bit academic right now. - 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] radeonfb: (#2) Implement proper workarounds for PLL accesses
On Thu, 2005-04-07 at 00:35 +0200, Andreas Schwab wrote: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > > > Hrm... it should only add a few ms, maybe about 20 ms to the mode > > switching... If you remove the radeon_msleep(5) call from the > > radeon_pll_errata_after_data() routine in radeonfb.h, does it make a > > difference ? > > Yes, it does. Without the sleep, switching is as fast as before. It is weird tho. Could you try adding a printk or something to figure out how much this is called during a typical swich ? It will seriously spam your console though ... I would expect only 5 or 6 calls during a normal switch (since the PLL value shouldn't change for a flat panel), that is no more than maybe 50ms, while it seems you are having a much bigger delay. Ben. - 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.12-rc2
On Wed, 2005-04-06 at 19:14 +0200, Moritz Muehlenhoff wrote: > Linus Torvalds wrote: > > Benjamin Herrenschmidt: > > o radeonfb: Implement proper workarounds for PLL accesses > > o radeonfb: DDC i2c fix > > o radeonfb: Fix mode setting on CRT monitors > > o radeonfb: Preserve TMDS setting > > One of these patches introduced two regressions on my Thinkpad X31 with > "ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA])": > > 1. When resuming from S3 suspend and having switched off the backlight > with radeontool the backlight isn't switched back on any more. I'm not sure what's up here, it's a nasty issue with backlight. Can radeontool bring it back ? > 2. I'm using fbcon as my primary work environment, but tty switching has > become _very_ sloppy, it's at least a second now, while with 2.6.11 it > was as fast as a few ms. Is this caused by the "proper PLL accesses"? Yes. Unfortunately. It's surprised it is that slow though, there shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with 5ms pause for each, that should still be very reasonable. It looks like we are doing a lot more accesses which I don't completely understand. Ben. - 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: Kernel SCM saga..
[EMAIL PROTECTED] wrote: Linus Torvalds wrote: PS. Don't bother telling me about subversion. If you must, start reading up on "monotone". That seems to be the most viable alternative, but don't pester the developers so much that they don't get any work done. They are already aware of my problems ;) By the way, the Subversion developers have no argument with the claim that Subversion would not be the right choice for Linux kernel development. We've written an open letter entitled "Please Stop Bugging Linus Torvalds About Subversion" to explain why: http://subversion.tigris.org/subversion-linus.html A thoughtful post. Thanks for writing this. 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] radeonfb: (#2) Implement proper workarounds for PLL accesses
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > Hrm... it should only add a few ms, maybe about 20 ms to the mode > switching... If you remove the radeon_msleep(5) call from the > radeon_pll_errata_after_data() routine in radeonfb.h, does it make a > difference ? Yes, it does. Without the sleep, switching is as fast as before. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - 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.11.6 1/6] irq and pci_ids: patch for Intel ESB2
Jason Gaston <[EMAIL PROTECTED]> wrote: > > Do I also need to create and submit these patches for 2.6.12-rc2 in > order to get them into 2.6.12 or will these make it into 2.6.12 as is? Is OK - I'll take care of the patch, thanks. - 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: non-fatal oops with EIP at skb_release_data, available for debugging
Quoting my post of over a month ago, hit another non-fatal oops this time with 2.6.12-rc1-bk2... [17330.816664] Adding 232932k swap on /dev/hdb4. Priority:-2 extents:1 [42120.713332] UDP: bad checksum. From 84.188.199.xxx:57483 to 192.168.1.7:10600 ulen 27 [56984.872784] UDP: bad checksum. From 216.155.90.xxx:11417 to 192.168.1.7:10600 ulen 28 [383152.586711] scsi: unknown opcode 0x01 [630539.047761] UDP: short packet: From 4.46.101.xxx:5431 58/27 to 192.168.1.7:1 0600 [681405.777002] [ cut here ] [681405.777337] kernel BUG at include/linux/mm.h:343! [681405.777642] invalid operand: [#1] [681405.777885] PREEMPT [681405.778041] Modules linked in: parport_pc parport 8139too floppy [681405.778488] CPU:0 [681405.778491] EIP:0060:[]Not tainted VLI [681405.778494] EFLAGS: 00210256 (2.6.12-rc1-bk2) [681405.779293] EIP is at skb_release_data+0xa3/0xb0 [681405.779593] eax: ebx: 0002 ecx: ceb1af80 edx: c10eeb40 [681405.780027] esi: c30785c0 edi: c30785c0 ebp: ccd95d28 esp: ccd95d20 [681405.780458] ds: 007b es: 007b ss: 0068 [681405.780723] Process metacity (pid: 2190, threadinfo=ccd94000 task=cb501a40) [681405.781164] Stack: c30785c0 0020 ccd95d34 c02dcd3b cec7a6c0 ccd95d54 c02 dcdb7 ccd95f3c [681405.781807]1620 c30785c0 506c6f85 c30785c0 506c6f85 ccd95da8 c03 0100a [681405.782448]c02dc46f caf7d420 ccd95d80 0001 caf7d46c ccd94000 000 1 [681405.783088] Call Trace: [681405.783258] [] show_stack+0x7a/0x90 [681405.783574] [] show_registers+0x14d/0x1c0 [681405.783915] [] die+0xe4/0x170 [681405.784192] [] do_invalid_op+0xa3/0xb0 [681405.784517] [] error_code+0x2b/0x30 [681405.785009] [] kfree_skbmem+0xb/0x20 [681405.785494] [] __kfree_skb+0x67/0xf0 [681405.785978] [] tcp_recvmsg+0x5fa/0x720 [681405.786477] [] sock_common_recvmsg+0x46/0x60 [681405.787004] [] sock_recvmsg+0xbd/0xf0 [681405.787493] [] sock_readv_writev+0x83/0x90 [681405.788009] [] sock_readv+0x3b/0x50 [681405.788487] [] do_readv_writev+0x205/0x230 [681405.789004] [] vfs_readv+0x3d/0x50 [681405.789476] [] sys_readv+0x3d/0xa0 [681405.789947] [] sysenter_past_esp+0x54/0x75 [681405.790461] Code: 8b 86 98 00 00 00 5e c9 e9 7b e9 e5 ff 89 d0 e8 44 f7 e5 f f eb d6 89 f0 e8 fb fe ff ff 5b 8b 86 98 00 00 00 5e c9 e9 5d e9 e5 ff <0f> 0b 5 7 01 32 ed 35 c0 eb ac 8d 76 00 55 89 e5 53 89 c3 e8 45 [681405.857278] <7>UDP: short packet: From 213.23.1.xxx:11236 2814/33 to 192.168. 1.7:10600 On Mar 4, 2005 10:48 PM, Alessandro Suardi <[EMAIL PROTECTED]> wrote: > This is my K7-800, 256MB RAM machine running as > ed2k/bittorrent 24/7 box... metacity died, but the > windows are still alive (and working) so if someone > wants to get more info about it, just ping me... > > [EMAIL PROTECTED] ~]# cat /proc/version > Linux version 2.6.11-rc3-bk8 ([EMAIL PROTECTED]) (gcc version 3.4.2 > 20041017 (Red Hat 3.4.2-6.fc3)) #1 Sat Feb 12 00:01:28 CET 2005 > [EMAIL PROTECTED] ~]# lsmod > Module Size Used by > loop 15368 - > nls_iso8859_1 3840 - > parport_pc 29444 - > parport24704 - > 8139too24896 - > floppy 57392 - > > From the dmesg ring: > > kernel BUG at include/linux/mm.h:343! > invalid operand: [#1] > PREEMPT > Modules linked in: loop nls_iso8859_1 parport_pc parport 8139too floppy > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00210256 (2.6.11-rc3-bk8) > EIP is at skb_release_data+0x92/0xa0 > eax: ebx: ecx: cca36f80 edx: c11a97c0 > esi: c4205f20 edi: c4205f20 ebp: cd149dcc esp: cd149dc4 > ds: 007b es: 007b ss: 0068 > Process metacity (pid: 2109, threadinfo=cd148000 task=ce8935d0) > Stack: c4205f20 cd149dd8 c02da6bb c6e9a0c0 cd149df8 c02da737 c5134250 > c4205f20 c5134250 c4205f20 c5134250 cd149e4c c02feba6 >0040 cc68c454 0001 cc68c444 cd148000 0001 > Call Trace: > [] show_stack+0x7a/0x90 > [] show_registers+0x14d/0x1c0 > [] die+0xe4/0x180 > [] do_invalid_op+0xa3/0xb0 > [] error_code+0x2b/0x30 > [] kfree_skbmem+0xb/0x20 > [] __kfree_skb+0x67/0xf0 > [] tcp_recvmsg+0x5f6/0x710 > [] sock_common_recvmsg+0x46/0x60 > [] sock_aio_read+0xee/0x100 > [] do_sync_read+0x97/0xf0 > [] vfs_read+0x91/0x120 > [] sys_read+0x3d/0x70 > [] sysenter_past_esp+0x52/0x75 > Code: c9 e9 03 e5 e5 ff 8d 76 00 5b 5e c9 c3 89 d0 e8 c5 f2 e5 ff eb > cf 89 f0 e8 0c ff ff ff 5b 8b 86 98 00 00 00 5e c9 e9 de e4 e5 ff <0f> > 0b 57 01 ab c5 35 c0 eb a5 8d 74 26 00 55 89 e5 53 89 c3 e8 --alessandro "I want to know if it's you I don't trust 'cause I damn sure don't trust myself" (Bruce Springsteen, "Brilliant Disguise") - 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
Re: 2.6.12-rc2 compile error in drivers/usb/class/cdc-acm.c
Ben Castricum <[EMAIL PROTECTED]> wrote: > > > > On Wed, 6 Apr 2005, Adrian Bunk wrote: > > > On Tue, Apr 05, 2005 at 10:54:09AM +0200, Ben Castricum wrote: > > > ... > > > CC fs/quota_v2.o > > > fs/quota_v2.c: In function `v2_write_dquot': > > > fs/quota_v2.c:399: warning: unknown conversion type character `z' in > > > format > > > fs/quota_v2.c:399: warning: too many arguments for format > > > > These are warnings that only occur with gcc 2.95 and that can safely be > > ignored. > > Just wondering, isn't 2.95.3 the recommended compiler anymore? I only use > this (a bit old) version because it's _the_ compiler for the kernel. > > If it still is then I find it a bit strange that code is accepted that > doesn't compile cleanly on the recommended compiler. > gcc-2.95.x requires %Z, not %z. The latter is more correct, and not many people use gcc-2.95.x, so we'll just have to live with the warnings, I'm afraid. I patched my gcc-2.95.4 to understand %z, but seem to have not put the patch anywhere where I can find it. - 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.12-rc2-mm1
Neil Brown <[EMAIL PROTECTED]> wrote: > > On Tuesday April 5, [EMAIL PROTECTED] wrote: > > > > - Nobody said anything about the PM resume and DRI behaviour in > > 2.6.12-rc1-mm4. So it's all perfect now? > > Well, Seeing you asked... > > PM resume certainly seems to be improving. > My main problem in rc1-mm3 is with PCMCIA. > If I stop cardmgr before suspend-to-RAM, and then try to > restart it after resume, I cannot. Some message about the socket > being in use, and am I sure there is no other cardmgr running (there > isn't). I don't know whether the PCMCIA problem is due to PCMCIA changes or not. The only thing I see having changed between 2.6.12-rc1-mm3 and 2.6.12-rc2-mm1 is the addition of pcmcia-resource-handling-fixes.patch. Would you have time to revert that, retest? There have been a few problem in the area of device management in bk-driver-core. I think we're getting that settled down now. - 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][RFC] disable built-in modules V2
On Apr 6, 2005 4:28 PM, Malcolm Rowe <[EMAIL PROTECTED]> wrote:
> Magnus Damm writes:
> > And I guess the idea of replacing the initcall pointer with NULL will
> > work both with and without function descriptors, right? So we should
> > be safe on IA64 and PPC64.
>
> I think so, though I don't really know a great deal about this area.
>
> An IA64 descriptor is of the form { , _context }, and a function
> pointer is a pointer to such a descriptor. Presumably, setting a function
> pointer to NULL will either end up setting the pointer-to-descriptor to NULL
> or the code pointer to NULL, but either way, I would expect the 'if
> (!*call)' comparison to work as intended.
>
> Best thing would be to get someone on IA64 and/or PPC64 to check this for
> you.
I agree. Do we have any friendly IA64/PPC64 user out there?
> Also might be worth checking that the patch works as intended with
> CONFIG_MODULES=n (assuming you haven't already).
The code works both with CONFIG_MODULES set to "y" and unset.
Thanks,
/ magnus
-
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] Re: clock runs at double speed on x86_64 system w/ATI RS200 chipset (workaround for APIC mode?)
The attached patch gets the clock to work normally for me without
disabling APIC mode entirely. But I'm still not sure what's going on.
dmesg of 2.6.11.6 with default options (ACPI, APIC, 'apic=debug'):
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/dmesg-2.6.11.6-acpi-apicdebug
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/interrupts-2.6.11-6-acpi-apic
dmesg with patch, and 'timerhack apic=debug':
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/dmesg-2.6.11.6-acpi-apicdebug-timerhack
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/interrupts-2.6.11-6-acpi-apic-timerhack
The patch causes the timer to be routed via the "Virtual Wire IRQ" mode,
and I see in /proc/interrupts:
0: 376947 local-APIC-edge timer
instead of 'IO-APIC-edge'. I no longer get duplicate timer interrupts; it
seems to track the 'LOC' interrupt count normally.
The crucial part of the patch, besides skipping attempting to set up the
timer IRQ through the APIC mp_INT or mp_ExtINT, is:
clear_IO_APIC_pin(0, pin1)
Without this function call, I still get duplicate timer interrupts when
using Virtual Wire to route the timer.
I'm still seeing 'APIC error on CPU0: 00(40)' messages from time to time.
-Chris
[EMAIL PROTECTED]
--- linux-2.6.11.6/arch/x86_64/kernel/io_apic.c.orig2005-03-25
22:28:21.0 -0500
+++ linux-2.6.11.6/arch/x86_64/kernel/io_apic.c 2005-04-06 17:56:46.486511088
-0400
@@ -1564,6 +1564,8 @@
* is so screwy. Thanks to Brian Perkins for testing/hacking this beast
* fanatically on his truly buggy board.
*/
+static int timer_hack = 0;
+
static inline void check_timer(void)
{
int pin1, pin2;
@@ -1592,6 +1594,10 @@
apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X pin1=%d
pin2=%d\n", vector, pin1, pin2);
+if (timer_hack) {
+ /* for some reason this stops duplicate timer IRQ? */
+ clear_IO_APIC_pin(0, pin1);
+} else {
if (pin1 != -1) {
/*
* Ok, does IRQ0 through the IOAPIC work?
@@ -1633,6 +1639,7 @@
clear_IO_APIC_pin(0, pin2);
}
printk(" failed.\n");
+}
if (nmi_watchdog) {
printk(KERN_WARNING "timer doesn't work through the IO-APIC -
disabling NMI Watchdog!\n");
@@ -1669,6 +1676,14 @@
panic("IO-APIC + timer doesn't work! Try using the 'noapic' kernel
parameter\n");
}
+static int __init timerhack(char *str)
+{
+ timer_hack = 1;
+ return 1;
+}
+__setup("timerhack", timerhack);
+
+
/*
*
* IRQ's that are handled by the PIC in the MPS IOAPIC case.
-
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.12-rc2-mm1
Jindrich Makovicka <[EMAIL PROTECTED]> wrote:
>
> oes not compile on AthlonXP. For mmx_clear_page, only the prototype was
> changed, but the implementation is still the same. I guess that part of
> the patch slipped out somehow.
>
> -extern void mmx_clear_page(void *page);
>
> +extern void mmx_clear_page(void *page, int order);
I guess this will fix it...
diff -puN
arch/i386/lib/mmx.c~add-a-clear_pages-function-to-clear-pages-of-higher-fix
arch/i386/lib/mmx.c
---
25/arch/i386/lib/mmx.c~add-a-clear_pages-function-to-clear-pages-of-higher-fix
Wed Apr 6 15:00:54 2005
+++ 25-akpm/arch/i386/lib/mmx.c Wed Apr 6 15:06:09 2005
@@ -128,9 +128,10 @@ void *_mmx_memcpy(void *to, const void *
* other MMX using processors do not.
*/
-static void fast_clear_page(void *page)
+static void fast_clear_page(void *page, int order)
{
int i;
+ int chunks = (4096 << order) / 64;
kernel_fpu_begin();
@@ -138,8 +139,7 @@ static void fast_clear_page(void *page)
" pxor %%mm0, %%mm0\n" : :
);
- for(i=0;i<4096/64;i++)
- {
+ for (i = 0; i < chunks; i++) {
__asm__ __volatile__ (
" movntq %%mm0, (%0)\n"
" movntq %%mm0, 8(%0)\n"
@@ -257,18 +257,18 @@ static void fast_copy_page(void *to, voi
* Generic MMX implementation without K7 specific streaming
*/
-static void fast_clear_page(void *page)
+static void fast_clear_page(void *page, int order)
{
int i;
-
+ int chunks = (4096 << order) / 128;
+
kernel_fpu_begin();
__asm__ __volatile__ (
" pxor %%mm0, %%mm0\n" : :
);
- for(i=0;i<4096/128;i++)
- {
+ for (i = 0; i < chunks; i++) {
__asm__ __volatile__ (
" movq %%mm0, (%0)\n"
" movq %%mm0, 8(%0)\n"
@@ -359,23 +359,23 @@ static void fast_copy_page(void *to, voi
* Favour MMX for page clear and copy.
*/
-static void slow_zero_page(void * page)
+static void slow_zero_page(void *page, int order)
{
int d0, d1;
__asm__ __volatile__( \
"cld\n\t" \
"rep ; stosl" \
: "=" (d0), "=" (d1)
- :"a" (0),"1" (page),"0" (1024)
+ :"a" (0),"1" (page),"0" (1024 << order)
:"memory");
}
-void mmx_clear_page(void * page)
+void mmx_clear_page(void *page, int order)
{
if(unlikely(in_interrupt()))
- slow_zero_page(page);
+ slow_zero_page(page, order);
else
- fast_clear_page(page);
+ fast_clear_page(page, order);
}
static void slow_copy_page(void *to, void *from)
_
-
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: Kernel SCM saga..
Linus Torvalds wrote: > PS. Don't bother telling me about subversion. If you must, start reading > up on "monotone". That seems to be the most viable alternative, but don't > pester the developers so much that they don't get any work done. They are > already aware of my problems ;) By the way, the Subversion developers have no argument with the claim that Subversion would not be the right choice for Linux kernel development. We've written an open letter entitled "Please Stop Bugging Linus Torvalds About Subversion" to explain why: http://subversion.tigris.org/subversion-linus.html Best, -Karl Fogel (on behalf of the Subversion team) - 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: bdflush/rpciod high CPU utilization, profile does not make sense
on den 06.04.2005 Klokka 18:01 (+0200) skreiv Jakob Oestergaard: > What do I do? > > Performance sucks and the profiles do not make sense... > > Any suggestions would be greatly appreciated, A look at "nfsstat" might help, as might "netstat -s". In particular, I suggest looking at the "retrans" counter in nfsstat. When you say that TCP did not help, please note that if retrans is high, then using TCP with a large value for timeo (for instance -otimeo=600) is a good idea. It is IMHO a bug for the "mount" program to be setting default timeout values of less than 30 seconds when using TCP. Cheers, Trond -- Trond Myklebust <[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: 2.6.12-rc2-mm1
"Barry K. Nathan" <[EMAIL PROTECTED]> wrote: > > Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the > problem goes away if I remove this patch: > swsusp-enable-resume-from-initrd.patch That really helps, thanks. The patch looks fairly innocent. I'll give up on this and cc the developers. > (Recap of the problem in case this gets forwarded: Resume is almost > instant without the apparently-guilty patch. With the patch, resume > takes almost half an hour.) > > BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1: > With that kernel, suspend is also ridiculously slow (speed is comparable > to the slow resume with the aforementioned patch). 2.6.11-rc2 does not > have that problem. Does reverting swsusp-enable-resume-from-initrd.patch fix this also? > Also, with 2.6.12-rc2-mm1, this computer happens to hit the bug where > all the printk timestamps are 000.000 (don't take the # of > digits too literally). Probably unrelated, but I may as well mention it. > (System is an Athlon XP 2200+ with SiS chipset. I can't remember which > model of SiS chipset.) Yes, sorry. Reverting http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_hpet-or-config_numa-systems.patch will fix that one. - 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.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop
Yeah, I can do that, I don't need angry programmers chasing after me :-) Shawn. --- Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > So nobody minds if I make this into a CONFIG > option marked as Deprecated? :) > > Actually it should probably go through > > Documentation/feature-removal-schedule.txt > > ...and give it *long* timeout, since it is API > change. > Pavel > -- > People were complaining that M$ turns users into > beta-testers... > ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb > yvxr vg gung jnl! > - 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.12-rc2-mm1: ACPI=y, ACPI_BOOT=n problems
Steven Cole <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > Steven Cole <[EMAIL PROTECTED]> wrote: > > > >>arch/i386/kernel/setup.c: In function 'setup_arch': > >> arch/i386/kernel/setup.c:1571: warning: implicit declaration of function > >> 'acpi_boot_table_init' > >> arch/i386/kernel/setup.c:1572: warning: implicit declaration of function > >> 'acpi_boot_init' > > > > > > > > diff -puN include/linux/acpi.h~no-acpi-build-fix include/linux/acpi.h > > --- 25/include/linux/acpi.h~no-acpi-build-fix 2005-04-05 > > 00:14:46.0 -0700 > > +++ 25-akpm/include/linux/acpi.h2005-04-05 00:23:39.0 -0700 > > @@ -418,16 +418,6 @@ extern int sbf_port ; > [patch snipped] > > Yes, that worked with no CONFIG_ACPI. Thanks. OK, I'll keep spamming the acpi guys with it until they tell me to shut up. > On a slightly offtopic note, I'm now using this gcc: > gcc (GCC) 4.0.0 20050308 (Red Hat 4.0.0-0.32) > > I don't have any quantitative data at hand, this seems SLW. > I guess that's progress. But it slows down testing somewhat. > There's a reason why I persist in keeping the kernel working with gcc-2.95.4! - 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] Dynamic Tick version 050406-1
Tony Lindgren wrote: > Hi all, > > Here's an updated dyn-tick patch. Some minor fixes: Doesn't look so good here. I get this with 2.6.12-rc2 (plus a few other patches). Disabling Dynamic Tick makes everything happy again (it boots). [4294688.655000] Unable to handle kernel NULL pointer dereference at virtual address [4294688.656000] printing eip: [4294688.657000] c077f818 [4294688.659000] *pde = [4294688.66] Oops: [#1] [4294688.661000] PREEMPT [4294688.662000] Modules linked in: [4294688.663000] CPU:0 [4294688.663000] EIP:0060:[]Not tainted VLI [4294688.663000] EFLAGS: 00010202 (2.6.12-rc2-fs3) [4294688.666000] EIP is at dyn_tick_late_init+0x38/0x80 [4294688.667000] eax: ebx: c079f0c0 ecx: edx: f7c15d4c [4294688.668000] esi: f7f02000 edi: ebp: f7f03fb8 esp: f7f03fb4 [4294688.669000] ds: 007b es: 007b ss: 0068 [4294688.67] Process swapper (pid: 1, threadinfo=f7f02000 task=f7f01830) [4294688.67] Stack: c077a0e2 f7f03fd8 c076a956 c019bde8 c01002a0 c01002a0 000 [4294688.671000] f7f03fec c01002d5 007b 007b c0101365 [4294688.672000] [4294688.673000] Call Trace: [4294688.675000] [] show_stack+0x7a/0x90 [4294688.676000] [] show_registers+0x149/0x1c0 [4294688.677000] [] die+0x14a/0x2d0 [4294688.678000] [] do_page_fault+0x44e/0x633 [4294688.679000] [] error_code+0x4f/0x54 [4294688.68] [] do_initcalls+0x56/0xc0 [4294688.681000] [] init+0x35/0x110 [4294688.682000] [] kernel_thread_helper+0x5/0x10 [4294688.683000] Code: 83 ec 04 e8 3b 6b c0 ff ba 14 b7<7>eth0: no IPv6 routers present Frank -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] [4294667.296000] Linux version 2.6.12-rc2-fs3 ([EMAIL PROTECTED]) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #3 Wed Apr 6 13:14:48 MDT 2005 [4294667.296000] BIOS-provided physical RAM map: [4294667.296000] BIOS-e820: - 0009f000 (usable) [4294667.296000] BIOS-e820: 0009f000 - 000a (reserved) [4294667.296000] BIOS-e820: 0010 - 5ffae000 (usable) [4294667.296000] BIOS-e820: 5ffae000 - 6000 (reserved) [4294667.296000] BIOS-e820: feda - fee0 (reserved) [4294667.296000] BIOS-e820: ffb0 - 0001 (reserved) [4294667.296000] 639MB HIGHMEM available. [4294667.296000] 896MB LOWMEM available. [4294667.296000] DMI 2.3 present. [4294667.296000] ACPI: PM-Timer IO Port: 0x808 [4294667.296000] Allocating PCI resources starting at 6000 (gap: 6000:9eda) [4294667.296000] Built 1 zonelists [4294667.296000] Kernel command line: ro root=LABEL=/1 vga=794 nmi_watchdog=1 lapic console=tty0 console=ttyUSB0,9600 psmouse.proto=exps i8k.ignore_dmi:bool=true [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ single [4294667.296000] Unknown boot option `i8k.ignore_dmi:bool=true': ignoring [4294667.296000] netconsole: local port 6665 [4294667.296000] netconsole: local IP 128.187.171.101 [4294667.296000] netconsole: interface eth0 [4294667.296000] netconsole: remote port 5515[4294667.296000] netconsole: remote IP 128.187.171.102 [4294667.[4294667.296000] Console: colour dummy device 80x25 [4294667.298[4294667.472000] Capability LSM initialized as secondary [429466[4294667.472000] Checking 'hlt' instruction... OK. [4294667.4830[4294667.616000] checking if image is initramfs... it is [429466[4294667.75] Completing Region/Field/Buffer/Package initiali[4294667.881000] PCI: Transparent bridge - :00:1e.0 [4294667[4294668.309000] pnp: PnP ACPI: found 10 devices [4294668.31[4294668.534000] pnp: 00:01: ioport range 0x808-0x80f could not [4294668.607000] audit(1112798526.606:0): initialized [4294668.6[4294668.625000] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ [4294668.947000] * connector 1 of type 2 (CRT) : 2320 [4294668[4294671.384000] radeonfb: Monitor 1 type LCD found [4294671.384[4294671.384000] 320 x 400 [4294671.384000] 320 x 400 [4294671[4294671.384000] 1024 x 768 [4294671.384000] 1280 x 1024 [4294[4294671.384000] Setting up default mode based on panel info [42[4294671.492000] fb1: VESA VGA frame buffer device [4294671.4980[4294673.099000] agpgart: AGP aperture is 128M @ 0xe800 [429[4294673.156000] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ [4294673.205000] PPP generic driver version 2.4.2 [4294673.20800[4294676.218000] b44: eth0: Link is up at 100 Mbps, full duplex.[4294677.477000] ICH4: not 100% native mode: will probe irqs lat[4294682.079000] hda: cache flushes supported [4294682.081000] [4294682.253000] PCI: Enabling device :02:01.0 ( -> 0002[4294682.646000] Badness in device_release at drivers/base/core.[4294682.657000] Databook TCIC-2 PCMCIA probe: not found. [42946[4294682.683000] hub 1-0:1.0: 6 ports detected [4294682.705000] [4294682.781000]
Re: Use of C99 int types
On Apr 06, 2005, at 07:41, Renate Meijer wrote:
On Apr 6, 2005, at 12:11 AM, Kyle Moffett wrote:
Please don't remove Linux-Kernel from the CC, I think this is an
important discussion.
GAAH!!! Read my lips!!! Quit removing Linux-Kernel from the CC!!!
As I see it, there are a number of issues
- Use of double underscores invades compiler namespace (except in
those cases
where kernel definitions end up as the basis for definitions in
/usr/include/*, i.e.
those that actually are part of the C-implementation for Linux.
It is these that I'm talking about. This is exactly my point (The
cases where
the kernel definitions are part of /usr/include).
- Some type that does not conflict with compiler namespace to replace
the variety
of definitions for e.g. 32-bit unsigned integers we have now.
As I said, I don't care about this, so do whatever you want.
- Removal of anything prefixed with a double underscore from
non-C-implementation
files.
ATM, much of the stuff in include/linux and include/asm-* is considered
"C-implementation" because it is used from userspace. If you want to
clean
that up and start moving abi files to include/kernel-abi or somesuch,
feel
free, but that's a lot of work
Personally, I don't care what you feel like requiring for purely
in-kernel interfaces, but __{s,u}{8,16,32,64} must stay to avoid
namespace collisions with glibc in the kernel include files as used
by userspace.
Aye, but as I have pointed out several times, these types should be
restricted
to those files and *only* those files which eventually end up in the
compilers
includes. In every other place, they invite exactly the trouble they
are intended
to avoid.
Precisely.
So if you want to make the millions of patches, go right ahead, be my
guest. :-P
Until somebody steps forward to clean up the huge mess, nothing will
get done.
So in every place exept those files which may actually cause a
namespace conflict or
a bug because some newer version does not support __foobar, or changed
the
semantics. Since using any __foobar type implies relying on the
compiler internals,
which may change without prior notice, it is ipso facto undesirable.
Except the kernel wants to be optimized and work and use what features
are available.
The kernel uses __foobar stuff provided by the compiler because it has
gccX.h files
specifically designed to take compiler interfaces, provide backups when
they don't
exist, and use them (and their better checking) when they do.
This is kinda arguing semantics, but:
A particular set of software (linux+libc+gcc), running in a particular
translation environment (userspace) under particular control options
(Signals, nice values, etc), that performs translation of programs for
(emulating missing instructions), and supports execution of functions
(syscalls) in, a particular execution environment (also userspace).
Ok. And where exactly are linux and libc when compiling code for an
Atmel ATmega32 (40 pin DIL) using gcc?
Where do you get Atmel ATmega32 from? I _only_ care about what symbols
Linux can use, and as I've mentioned, when running under *Linux*, then
it just so
happens that *Linux* is part of my implementation, therefore the
*Linux* sources,
which by definition aren't used elsewhere, can assume they are part of
said
implementation.
The 'set of software' does
*not* include any OS. Not Windows, not Linux, not MacOSX, since the
whole thing might be directed at a lowly microcontroller, which DOES
NOT HAVE ANY OPERATING SYSTEM WHATSOEVER.
Nevertheless, gcc works fine.
This is unrelated and off topic. Heck, you've even consented above that
Linux can use
Without the kernel userspace wouldn't have anything, because anything
syscall-related (which is basically everything) involves the kernel.
Sure. The same goes for every other program. However, it would be
pretty
stoopid to say the kernel is an integral part of (say) the Gimp . More
so, since
the Gimp and GCC run on completely different architectures aswell.
By the same token, linux is part of XFree86 despite the fact XFree86
does not
require linux to run.
But an XFree86 binary compiled on FreeBSD, or a GIMP binary compiled on
FreeBSD,
for the most part, will not run on Linux, because the compiler uses the
_Linux_
environment to build the binary, including the _Linux_ headers and
such. The
built binary is nearly useless without Linux, but not vice-versa, hence
even
though the binary is not a derivative work of linux, it requires it to
run.
Heck, the kernel and its ABI is _more_ a part of the implementation
than glibc is! I can write an assembly program that doesn't link to
or use libc, but without using syscalls I can do nothing whatsoever.
I can write entire applications using gcc without even thinking of
using
any 'syscall' or any other part of linux/bsd/whatever. Still... it's
gcc.
Uhh, what exactly is your application going to do? So it wants to
access
memory, it faults to the kernel and gets stuff paged in. It wants to
Re: [OOPS] 2.6.11 - NMI lockup with CFQ scheduler
On Wed, 2005-04-06 at 21:08 +0200, Jens Axboe wrote: > > I think the correct model for all of this is that the block driver > > shouldn't care (or be tied to) the scsi one. Thus, as long as SCSI can > > reject requests from a queue whose device has been released (without > > checking the device) then everything is fine as long as we sort out the > > lock lifetime problem. > > But you are tying it completely to the SCSI problem, since we have no > locking problems of this sort elsewhere. At least the notified could > potentially be used for something else. The lock is just hack number two > to work around the problem. Then help me understand the problem as you see it. My current understanding is that these problems occur because we've mixed data in two objects of different lifetimes. So far, this is stack independent. My proposal is to correct this by moving the data back to the correct object, and make any object using it hold a reference, so this would make the provider of the block request_fn hold a reference to the queue and initialise the queue lock pointer with the lock currently in the queue. Drivers that still use a global lock would be unaffected. This also means that any provider of a request_fn may expect to process (and reject) requests for a period of time after blk_cleanup_queue(). Really, this refcounting is inherent in blk_init_queue(), blk_cleanup_queue() so the only additional requirement is sanely processing queue requests after you think it's been cleaned up. This is request_fn() provider independent, I think (providers who currently don't violate the lifetime rules don't need fixing). I claim that this proposal solves the current problem, and any other ones we run across that occur because of data mixing. Your current patch tries to solve the problem by tying the two objects together; unifying the lifetimes. I agree this can be done (it was how the sd/sr close race was fixed). But the current way the freeing functions thread across the subsystems doesn't look nice and I don't currently see a way to get the queue freed: We free the queue on scsi device release; if the queue holds a reference to the scsi_device, the release function will never be called. Our only other choice is to try to free the queue on device_del instead, but that's too early, I think. James - 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/4] create mm/Kconfig for arch-independent memory options
On Wed, 2005-04-06 at 22:58 +0200, Roman Zippel wrote: > Dave Hansen wrote: > > --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0 > > -0700 > > +++ memhotplug-dave/mm/Kconfig 2005-04-04 10:15:23.0 -0700 > > @@ -0,0 +1,25 @@ > > +choice > > + prompt "Memory model" > > + default FLATMEM > > + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT > > + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT > > Does this really have to be a user visible option and can't it be > derived from other values? The help text entries are really no help at all. I hope that this selection will replace the current DISCONTIGMEM prompts in the individual architectures. That way, you won't get a net increase in the number of prompts. However, I do realize that architectures without DISCONTIG see a new, relatively useless menu/prompt. Is there a way to hide an entire "choice" menu? If there is, we can certainly hide it when there's only one possible choice. -- 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: kernel panic - not syncing: Fatal exception in interupt
No, sorry, i have to run with bridging support other wise the guests(UML's) wont be able to communicate with the outside world. Best Regards, Shaun R - Original Message - From: "Zwane Mwaikambo" <[EMAIL PROTECTED]> To: "shaun" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, April 06, 2005 1:10 AM Subject: Re: kernel panic - not syncing: Fatal exception in interupt > On Tue, 5 Apr 2005, shaun wrote: > > > +Hardware Specs > > Dual Xeon 800FSB > > Intel Server Board > > 4GB ECC DDR > > 3ware 9500 Sata Raid Card > > 5x200 GB sata drives in a raid 10 Config (1 hot spare) > > Dual Nic > > > > +OS Specs > > CentOS 3.4 running a custom 2.6.x kernel patched with UML SKA's Patch > > eth0 is 0.0.0.0 promisc and assigned to a bridge (br0) > > tuntap devices up > > ebtables is enabled and loaded with rules > > Is it possible to run without the bridge for testing purposes, and be > sure to put the normal networking load? > > > My problem is that every other week or so the machine crashes. It never > > dumps the error to the logs so all i have is a screen shot of the console. > > I have put some serious stress on this machine and have been unable to > > duplicate the problem (running 20 guest UML's half running va-ctcs and the > > other half compiling a 2.6 kernel). Below is a link to 2 screen shots i > > have (about 2 weeks apart). I started off using a 2.6.10 kernel when the > > problem started. Last time the machine crashed i built a 2.6.11.5 kernel > > and disabled APM and ACPI in the kernel config. Any body know whats going > > on here. > > > > http://www.unix-scripts.com/shaun/host-screenshot-1.png > > http://www.unix-scripts.com/shaun/host-screenshot-2.png > > > > Kernel Config... http://www.unix-scripts.com/shaun/2.6.11.5-hr1_.config > > > > -- > > Best Regards, > > > > Shaun Reitan > > > > > > > > > > - > > 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/ > > > - 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/4] create mm/Kconfig for arch-independent memory options
Hi, Dave Hansen wrote: > diff -puN mm/Kconfig~A6-mm-Kconfig mm/Kconfig > --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0 > -0700 > +++ memhotplug-dave/mm/Kconfig2005-04-04 10:15:23.0 -0700 > @@ -0,0 +1,25 @@ > +choice > + prompt "Memory model" > + default FLATMEM > + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT > + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT Does this really have to be a user visible option and can't it be derived from other values? The help text entries are really no help at all. bye, Roman - 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: Light Scribe Technology
--- "John W. Linville" <[EMAIL PROTECTED]> wrote: > On Wed, Apr 06, 2005 at 12:56:35PM -0700, Alan Bryan > wrote: > > > Can you tell me if there is currently support in > the > > kernel for HP's new LightScribe technology? > > > (http://h30015.www3.hp.com/hp_dec/lightscribe/index_FL.asp). > > If there is not, are there plans for it? > > I don't know of any. Are the specs on the hardware > open? > -- > John W. Linville > [EMAIL PROTECTED] > - To be honest, I'm not sure. I wrote an email to HP using the address on their LightScribe technology page, but they never responded...I'm thinking that's a big noBut there are Windows drivers to reverese engineer...How fun! __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - 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/Patch 2.6.11] Take control of PCI Master Abort Mode
On 05.04.2005, at 21:33, Ross Biro wrote: The problem with always setting the bit is that some PCI hardware, notably some Intel E-1000 chips (Ethernet controller: Intel Corporation: Unknown device 1076) cannot properly handle the target abort bit. In the case of the E-1000 chip, the driver must reset the chip to recover. This usually leads to the machine being off the network for several seconds, or sometimes even minutes, which can be bad for servers. This sounds *exactly* like my problem since I swapped motherboards. I'll see whether there's some option in the BIOS that fixes it and if not bite the bullet and compile a generic kernel Thanks a lot for investigating this. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> Josselin Mouette wrote: > >It merely depends on the definition of "aggregation". I'd say that two > >works that are only aggregated can be easily distinguished and > >separated. This is not the case for a binary kernel module, from which > >you cannot easily extract the firmware and code parts. On Tue, Apr 05, 2005 at 04:00:32PM -0300, Humberto Massa wrote: > Not really... As a matter of fact, it's quite easy to separate those > parts, at least as easy as it is to separate one story inside a book > that contains an anthology of short stories. And the latter is not > considered a derivative work, either. I'm not sure who it is that doesn't consider anthologies a derivative work. The u.s. copyright office considers anthologies and other compilations derivative works except when they involve insufficient creative work to grant them copyright protection. http://www.copyright.gov/circs/circ14.pdf But it's probably not interesting to argue any further about the inner workings of copyright law. Pretty much everyone seems to agree on what the right approach is, here. The big issue seems to be stability of linux during the transition. The interesting topics, at this point, have to do with the details of migrating such drivers out of the kernel. -- Raul - 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: clock runs at double speed on x86_64 system w/ATI RS200 chipset
I noticed that the x86_64 kernel has 4 different ways of configuring the
timer interrupt in APIC mode:
arch/x86_64/kernel/io_apic.c :
/* style 1 */
if (pin1 != -1) {
/*
* Ok, does IRQ0 through the IOAPIC work?
*/
/* style 2 */
apic_printk(APIC_VERBOSE,KERN_INFO "...trying to set up timer (IRQ0)
through the 8259A ... ");
if (pin2 != -1) {
apic_printk(APIC_VERBOSE,"\n. (found pin %d) ...", pin2);
/*
* legacy devices should be connected to IO APIC #0
*/
/* style 3 */
apic_printk(APIC_VERBOSE, KERN_INFO "...trying to set up timer as
Virtual Wire IRQ...");
/* style 4 */
apic_printk(APIC_VERBOSE, KERN_INFO "...trying to set up timer as
ExtINT IRQ...");
I hacked the kernel with the following patch to try using all 4 timer
configurations. (by overriding 'pin1' and 'pin2', and by bypassing the
code that sets up 'Virtual Wire IRQ')
Unfortunately I wasn't able to change the behavior in any case. I couldn't
get the last configuration ('trying to set up timer as ExtINT IRQ') to
work; the machine just hung. I'm guessing that the code
io_apic.c::unlock_ExtINT_logic() may have never been tested on AMD chips?
No matter what I did, the clock still ran at double normal speed. Perhaps
we are just programming the APIC incorrectly for this board in some way?
booting with standard options (ACPI enabled, 'apic=debug'); this uses
method 1:
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/dmesg-2.6.11.6-acpi-apicdebug
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/interrupts-2.6.11-6-acpi-apic
booting with 'force_apic_timer=-1,0 apic=debug' to force it to use method
#2 to route the timer interrupt:
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/dmesg-2.6.11.6-acpi-apicdebug-forcetimer=-1,0
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/interrupts-2.6.11-6-acpi-apic-forcetimer=-1,0
booting with 'force_apic_timer=-1,-1 apic=debug' to force it to use method
#3:
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/dmesg-2.6.11.6-acpi-apicdebug-forcetimer=-1,-1
http://www-personal.engin.umich.edu/~wingc/apictimer/dmesg/interrupts-2.6.11-6-acpi-apic-forcetimer=-1,-1
(note that /proc/interrupts says 'local-APIC-edge' for timer
interrupt, but it still receives twice as many interrupts)
booting with 'force_apic_timer=-1,-1 novwtimer apic=debug' to force it to
use method #4:
(machine just hangs when trying to set up the timer)
-Chris
[EMAIL PROTECTED]
--- linux-2.6.11.6/arch/x86_64/kernel/io_apic.c.orig2005-03-25
22:28:21.0 -0500
+++ linux-2.6.11.6/arch/x86_64/kernel/io_apic.c 2005-04-06 16:28:25.120441232
-0400
@@ -1564,6 +1564,10 @@
* is so screwy. Thanks to Brian Perkins for testing/hacking this beast
* fanatically on his truly buggy board.
*/
+static int apic_timer_forced = 0;
+static int force_pin1, force_pin2;
+static int force_novwtimer = 0;
+
static inline void check_timer(void)
{
int pin1, pin2;
@@ -1587,8 +1591,13 @@
init_8259A(1);
enable_8259A_irq(0);
- pin1 = find_isa_irq_pin(0, mp_INT);
- pin2 = find_isa_irq_pin(0, mp_ExtINT);
+ if (apic_timer_forced) {
+ pin1 = force_pin1;
+ pin2 = force_pin2;
+ } else {
+ pin1 = find_isa_irq_pin(0, mp_INT);
+ pin2 = find_isa_irq_pin(0, mp_ExtINT);
+ }
apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X pin1=%d
pin2=%d\n", vector, pin1, pin2);
@@ -1639,6 +1648,7 @@
nmi_watchdog = 0;
}
+if (!force_novwtimer) {
apic_printk(APIC_VERBOSE, KERN_INFO "...trying to set up timer as
Virtual Wire IRQ...");
disable_8259A_irq(0);
@@ -1652,6 +1662,7 @@
}
apic_write_around(APIC_LVT0, APIC_LVT_MASKED | APIC_DM_FIXED | vector);
apic_printk(APIC_VERBOSE," failed.\n");
+}
apic_printk(APIC_VERBOSE, KERN_INFO "...trying to set up timer as
ExtINT IRQ...");
@@ -1669,6 +1680,41 @@
panic("IO-APIC + timer doesn't work! Try using the 'noapic' kernel
parameter\n");
}
+static int __init force_apic_timer(char *str)
+{
+ int timer_irqs[3];
+
+ get_options(str, ARRAY_SIZE(timer_irqs), timer_irqs);
+ if (timer_irqs[0] != 2) {
+ printk(KERN_WARNING "force_apic_timer must specify
pin1,pin2\n");
+ goto out;
+ }
+
+ apic_timer_forced = 1;
+ force_pin1 = timer_irqs[1];
+ force_pin2 = timer_irqs[2];
+
+out:
+ return 1;
+}
+
+static int __init novwtimer(char *str)
+{
+ force_novwtimer = 1;
+ return 1;
+}
+
+static int __init noirq(char *str)
+{
+ force_noirq = 1;
+ return 1;
+}
+
+__setup("force_apic_timer=", force_apic_timer);
+__setup("novwtimer", novwtimer);
+__setup("noirq", noirq);
RE: Kernel SCM saga..
> Even with a GPL'd Linux Bitkeeper I'll bet half of the existing Linux > paying customers will continue to use a paid version. By what? How much do you plan to put down to pay Larry in case you lose your bet? Hua - 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: Out of memory with Java 1.5 and 2.6.11.6
Apr 5 22:05:20 xine kernel: oom-killer: gfp_mask=0xd0 The oom-killer a piece of code which starts killing processes when you run out of memory. OOM-killer = Out Of Memory Killer. My guess is that the second jvm consumed all the memory left ( this may me be a memory leak, if so report it to SUN, not lkml ) and eclipse , being a memory-heavyweight got slaughtered. The first thing that came to mind :) On Wed, 2005-04-06 at 21:31 +0200, Robin Rosenberg wrote: > I see regular crashes with 2.6.11.6 (mandrake-patched) and Java 1.5.02 (01 > too > btw, but not 1.4.2). Gentoo people report the same problem sugesting that it > may have appeared between 2.6.11.4 and 2.6.11.5. > > If I start eclipse and then, outside of eclipse, starts a java 1.5 process > eclipse dies instantly. Not always, but usually when I stop watching. > > Any clues? > > -- robin > > oh, here is an excerpt from /var/log/messages. > > Apr 5 22:05:20 xine kernel: oom-killer: gfp_mask=0xd0 > Apr 5 22:05:20 xine kernel: DMA per-cpu: > Apr 5 22:05:20 xine kernel: cpu 0 hot: low 2, high 6, batch 1 > Apr 5 22:05:20 xine kernel: cpu 0 cold: low 0, high 2, batch 1 > Apr 5 22:05:20 xine kernel: Normal per-cpu: > Apr 5 22:05:20 xine kernel: cpu 0 hot: low 32, high 96, batch 16 > Apr 5 22:05:20 xine kernel: cpu 0 cold: low 0, high 32, batch 16 > Apr 5 22:05:20 xine kernel: HighMem per-cpu: empty > Apr 5 22:05:20 xine kernel: > Apr 5 22:05:20 xine kernel: Free pages:5684kB (0kB HighMem) > Apr 5 22:05:20 xine kernel: Active:107335 inactive:5929 dirty:0 writeback:4 > unstable:0 free:1421 slab:9726 mapped:113240 pagetables:1705 > Apr 5 22:05:20 xine kernel: DMA free:2068kB min:88kB low:108kB high:132kB > active:8392kB inactive:0kB present:16384kB pages_scanned:8802 > all_unreclaimable? yes > Apr 5 22:05:20 xine kernel: lowmem_reserve[]: 0 495 495 > Apr 5 22:05:21 xine kernel: Normal free:3616kB min:2800kB low:3500kB > high:4200kB active:420948kB inactive:23716kB present:507576kB pages_scanned:0 > all_unreclaimable? no > Apr 5 22:05:21 xine kernel: lowmem_reserve[]: 0 0 0 > Apr 5 22:05:21 xine kernel: HighMem free:0kB min:128kB low:160kB high:192kB > active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no > Apr 5 22:05:21 xine kernel: lowmem_reserve[]: 0 0 0 > Apr 5 22:05:21 xine kernel: DMA: 1*4kB 0*8kB 1*16kB 0*32kB 2*64kB 1*128kB > 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2068kB > Apr 5 22:05:21 xine kernel: Normal: 208*4kB 8*8kB 2*16kB 6*32kB 7*64kB > 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 3616kB > Apr 5 22:05:21 xine kernel: HighMem: empty > Apr 5 22:05:21 xine kernel: Swap cache: add 1267612, delete 1246233, find > 7825455/7951372, race 0+6 > Apr 5 22:05:21 xine kernel: Free swap = 760276kB > Apr 5 22:05:21 xine kernel: Total swap = 1060248kB > Apr 5 22:05:21 xine kernel: Out of Memory: Killed process 23770 (java). > - > 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/ > - 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: [OOPS] 2.6.11 - NMI lockup with CFQ scheduler
Tejun Heo [EMAIL PROTECTED] wrote: > Jens Axboe wrote: > >On Wed, Apr 06 2005, Arjan van de Ven wrote: > > > >>>@@ -324,6 +334,7 @@ > >>> issue_flush_fn *issue_flush_fn; > >>> prepare_flush_fn*prepare_flush_fn; > >>> end_flush_fn*end_flush_fn; > >>>+ release_queue_data_fn *release_queue_data_fn; > >>> > >>> /* > >>>* Auto-unplugging state > >> > >>where does this function method actually get called? > > > > > >I missed the hunk in ll_rw_blk.c, rmk pointed the same thing out not 5 > >minutes ago :-) > > > >The patch would not work anyways, as scsi_sysfs.c clears queuedata > >unconditionally. This is a better work-around, it just makes the queue > >hold a reference to the device as well only killing it when the queue is > >torn down. > > > >Still not super happy with it, but I don't see how to solve the circular > >dependency problem otherwise. > > > > Hello, Jens. > > I've been thinking about it for a while. The problem is that we're > reference counting two different objects to track lifetime of one > entity. This happens in both SCSI upper and mid layers. In the upper > layer, genhd and scsi_disk (or scsi_cd, ...) are ref'ed separately while > they share their destiny together (not really different entity) and in > the middle layer scsi_device and request_queue does the same thing. > Circular dependency is occuring because we separate one entity into two > and reference counting them separately. Two are actually one and > necessarily want each other. (until death aparts. Wow, serious. :-) > > IMHO, what we need to do is consolidate ref counting such that in each > layer only one object is reference counted, and the other object is > freed when the ref counted object is released. The object of choice > would be genhd in upper layer and request_queue in mid layer. All > ref-counting should be updated to only ref those objects. We'll need to > add a release callback to genhd and make request_queue properly > reference counted. > > Conceptually, scsi_disk extends genhd and scsi_device extends > request_queue. So, to go one step further, as what UL represents is > genhd (disk device) and ML request_queue (request-based device), > embedding scsi_disk into genhd and scsi_device into request_queue will > make the architecture clearer. To do this, we'll need something like > alloc_disk_with_udata(int minors, size_t udata_len) and the equivalent > for request_queue. > > I've done this half-way and then doing it without fixing the SCSI > model seemed silly so got into working on the state model. (BTW, the > state model is almost done, I'm about to run tests.) > > What do you think? Jens? Well I think extends is one way to look at the subsystem objects, Couldn't it also be said that these objects from each subsystem have just a relationship (parent / child, etc). As reference counting has been implemented in each subsystem sometimes interfaces that cross subsystem boundaries (had / have) not been converted to use similar life time rules. Well your solution tries to solve the problem by creating a new larger object that contains both of the old objects. Another solution would be to use a consistent lifetime rules and stay with smaller objects. Unless going to large objects helps with allocation fragmentation or we get some other benefit it would seem that these combined structures may sometime in the future limit creation of lighter or flexible objects. It would appear another solution is that when you allocate a resource from another subsystem (i.e. blk_init_queue) that both subsystems participate in the same reference counting model and in the allocation routine you past in your object to be referenced counted by the allocating subsystem. Then when it is time to shutdown you do not free the others subsystems object directly, but use the normal release routines. -andmike -- Michael Anderson [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: Light Scribe Technology
On Wed, Apr 06, 2005 at 12:56:35PM -0700, Alan Bryan wrote: > Can you tell me if there is currently support in the > kernel for HP's new LightScribe technology? > (http://h30015.www3.hp.com/hp_dec/lightscribe/index_FL.asp). > If there is not, are there plans for it? I don't know of any. Are the specs on the hardware open? -- John W. Linville [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: [stable] [patch 1/1] uml: quick fix syscall table [urgent]
On Wed, Apr 06, 2005 at 08:38:00PM +0200, [EMAIL PROTECTED] wrote: > > CC: <[EMAIL PROTECTED]> > > I'm resending this for inclusion in the -stable tree. I've deleted whitespace > cleanups, and hope this can be merged. I've been asked to split the former > patch, I don't know if I must split again this one, even because I don't want > to split this correct patch into multiple non-correct ones by mistake. Is this patch already in 2.6.12-rc2? thanks, greg k-h - 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 libipq kernel hang
All, I am having a kernel hang with all the latest versions of the 2.6 kernel (2.6.8.1, 2.6.9, 2.6.10, and 2.6.12-rc2). Basically, my test is this: I have a simple ipq program that just takes packets in, makes a copy of them (using memcpy), then accepts the packets with the new buffer (which happens to be a copy of the old buffer). I run this program on two machines, with the following iptables rules: /sbin/iptables -t mangle -A POSTROUTING -d 192.168.3.0/24 -j QUEUE /sbin/iptables -t mangle -A PREROUTING -s 192.168.3.0/24 -j QUEUE I then have a simple server and client program; the server just accepts a connection, recv's some data, and then closes the connection (in a while(1) loop). The client connects to the server, send's some data, then closes the connection (in a while(1) loop). With this test running, on all of the kernels mentioned above, the kernel will always hang after some length of time (it seems to be more or less random). No oops, no stack trace, just a hard kernel lock. I saw in the ChangeLog for 2.6.12-rc2 that they may have fixed a race condition in netlink; however, 2.6.12-rc2 still did not work for me. I have also tried running a server program that just accepts a connection, and recv's data forever, with a client that connects once, and send's data forever. This also locked up the machine, although with slightly different behavior (basically the queue program sucked up 100% of the processor for a while, then the whole kernel hung). All of the code I am using, along with the scripts can be found at http://www.ontologistics.net/OpenSource/libipq If anyone has any suggestions about what I am doing wrong in either the libipq program or the client or server programs, or any ideas about what is going on with netlink, please let me know. Thank you, Chris Lalancette P.S. Sorry if you get this twice; I don't think GMail sent it properly the first time. - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 03:28:01PM -0400, Jeff Garzik wrote: > * Most firmwares are a -collection- of images and data. The firmware > infrastructure should load an -archive- of firmwares and associated data > values. Why don't you use multiple firmware loading calls with different names? Maybe adding a "group" name, or simply adding a '/' in the name. That way the userspace half will have the choice between using directories, tar, zip or whatever. The speedtouch driver already requests multiple files, having them together in one file is a userspace problem which the kernel can help but shouldn't try to solve. > > * The firmware distribution infrastructure is basically non-existent. > There is no standard way to make sure that a firmware separated from the > driver gets to all users. That's the price how having non-gpl compatible firmware though. > * The firmware bundling infrastructure is basically non-existent. > (Arjan talked about this) There needs to be a a way to ensure that the > needed firmwares are automatically added to initramfs/initrd. Yes. See following too. > * There is no chicken-and-egg problem as Arjan mentions. Once the above > technical problems are resolved, its trivial to apply a firmware loading > patch. I believe in hard transitions, not shipping tg3 with firmware > -and- a firmware loading patch. An infrastructure to add a number of files to the kernel image (_not_ the initrd/initramfs) which can be found through internal kernel calls, firmware loading and probably an export in /proc would be nice. Unifying DSDT override, config.gz and early firmware could be nice. > * Firmwares such as tg3 should be shipped with the kernel tarball. Does it change between kernel versions? How often? OG. - 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-usb-devel] USB glitches after suspend on ppc
On Wednesday 06 April 2005 10:20 am, Colin Leroy wrote: > On 05 Apr 2005 at 13h04, David Brownell wrote: > > > > > > What kind of work on these is needed so that they get in? > > > > Briefly, given 2.6.12-rc2 plus the patches mentioned above, > > find out what else is needed. > > ... > > How's that sound? > > Nice :) > > Ok, here are the results of my tests with 2.6.12-rc2 and the patches > you sent me applied: > > - plug USB device, sleep, unplug USB device, resume: no more oops > - sleep, plug in USB device: no oops, but it wakes the laptop up for a > few seconds; then, it goes back to sleep. No oops on second resume. I > can live with that :) Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went back to sleep!) Do you think that might be related to those calls manipulating the Apple ASICs being in the OHCI layer rather than up nearer the generic PCI glue? (I still think they don't belong in USB code -- ohci or usbcore -- at all. If the platform-specific PCI hooks don't suffice, they need fixing.) Thanks for the testing update. I'm glad to know that there seems to be only one (minor) glitch that's PPC-specific! > - once out of two resumes, resume leaves the ports unpowered; so I still > need my usb-ehci-power.patch that re-powers ports unconditionnaly. OK, I just posted the patch cleaning up EHCI port power switching; that should remove the need for that separate patch. (As well as fixing some minor annoyances.) - 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: Linux 2.4.30-rc3 md/ext3 problems (ext3 gurus : please check)
Hi, On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote: > I have measured the bh refcount before the buffer_uptodate() for a few days. > I found out that the bh refcount sometimes reached to 0 . > So, I think following modifications are effective. Thanks --- it certainly looks like this should fix the dereferencing of invalid bh's, and this code mirrors what 2.6 does around that area. However, 2.6 is suspected of still having leaks in ext3. To be certain that we're not just backporting one of those to 2.4, we need to understand who exactly is going to clean up these bh's if they are in fact unused once we complete this code and do the final put_bh(). I'll give this patch a spin with Andrew's fsx-based leak stress and see if anything unpleasant appears. Cheers, Stephen - 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/1] uml: quick fix syscall table [urgent]
CC: <[EMAIL PROTECTED]> I'm resending this for inclusion in the -stable tree. I've deleted whitespace cleanups, and hope this can be merged. I've been asked to split the former patch, I don't know if I must split again this one, even because I don't want to split this correct patch into multiple non-correct ones by mistake. Uml 2.6.11 does not compile with gcc 2.95.4 because some entries are duplicated, and that GCC does not accept this (unlike gcc 3). Plus various other bugs in the syscall table definitions, resulting in probable wrong syscall entries: *) 223 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 it's a valid syscall (thus a duplicated one). *) __NR_vserver must be only once with sys_ni_syscall, and not multiple times with different values! *) syscalls duplicated in SUBARCHs and in common files (thus assigning twice to the same array entry and causing the GCC 2.95.4 failure mentioned above): sys_utimes, which is common, and sys_fadvise64_64, sys_statfs64, sys_fstatfs64, which exist only on i386. *) syscalls duplicated in each SUBARCH, to put in common files: sys_remap_file_pages, sys_utimes, sys_fadvise64 *) 285 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 the range does not arrive to that point. *) on x86_64, the macro name is __NR_kexec_load and not __NR_sys_kexec_load. Use the correct name in either case. Note: as you can see, part of the syscall table definition in UML is arch-independent (with everywhere defined syscalls), and part is arch-dependant. This has created confusion (some syscalls are listed in both places, some in the wrong one, some are wrong on one arch or another). Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> --- clean-linux-2.6.11-paolo/arch/um/include/sysdep-i386/syscalls.h | 12 +- clean-linux-2.6.11-paolo/arch/um/include/sysdep-x86_64/syscalls.h |5 clean-linux-2.6.11-paolo/arch/um/kernel/sys_call_table.c | 11 +++-- 3 files changed, 10 insertions(+), 18 deletions(-) diff -puN arch/um/include/sysdep-i386/syscalls.h~uml-quick-fix-syscall-table-for-stable arch/um/include/sysdep-i386/syscalls.h --- clean-linux-2.6.11/arch/um/include/sysdep-i386/syscalls.h~uml-quick-fix-syscall-table-for-stable 2005-04-05 16:56:57.0 +0200 +++ clean-linux-2.6.11-paolo/arch/um/include/sysdep-i386/syscalls.h 2005-04-05 16:56:57.0 +0200 @@ -23,6 +23,9 @@ extern long sys_mmap2(unsigned long addr unsigned long prot, unsigned long flags, unsigned long fd, unsigned long pgoff); +/* On i386 they choose a meaningless naming.*/ +#define __NR_kexec_load __NR_sys_kexec_load + #define ARCH_SYSCALLS \ [ __NR_waitpid ] = (syscall_handler_t *) sys_waitpid, \ [ __NR_break ] = (syscall_handler_t *) sys_ni_syscall, \ @@ -101,15 +104,12 @@ extern long sys_mmap2(unsigned long addr [ 223 ] = (syscall_handler_t *) sys_ni_syscall, \ [ __NR_set_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \ [ __NR_get_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \ - [ __NR_fadvise64 ] = (syscall_handler_t *) sys_fadvise64, \ [ 251 ] = (syscall_handler_t *) sys_ni_syscall, \ -[ __NR_remap_file_pages ] = (syscall_handler_t *) sys_remap_file_pages, \ - [ __NR_utimes ] = (syscall_handler_t *) sys_utimes, \ - [ __NR_vserver ] = (syscall_handler_t *) sys_ni_syscall, - + [ 285 ] = (syscall_handler_t *) sys_ni_syscall, + /* 222 doesn't yet have a name in include/asm-i386/unistd.h */ -#define LAST_ARCH_SYSCALL __NR_vserver +#define LAST_ARCH_SYSCALL 285 /* * Overrides for Emacs so that we follow Linus's tabbing style. diff -puN arch/um/include/sysdep-x86_64/syscalls.h~uml-quick-fix-syscall-table-for-stable arch/um/include/sysdep-x86_64/syscalls.h --- clean-linux-2.6.11/arch/um/include/sysdep-x86_64/syscalls.h~uml-quick-fix-syscall-table-for-stable 2005-04-05 16:56:57.0 +0200 +++ clean-linux-2.6.11-paolo/arch/um/include/sysdep-x86_64/syscalls.h 2005-04-05 16:56:57.0 +0200 @@ -71,12 +71,7 @@ extern syscall_handler_t sys_arch_prctl; [ __NR_iopl ] = (syscall_handler_t *) sys_ni_syscall, \ [ __NR_set_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \ [ __NR_get_thread_area ] = (syscall_handler_t *) sys_ni_syscall, \ -[ __NR_remap_file_pages ] = (syscall_handler_t *) sys_remap_file_pages, \ [ __NR_semtimedop ] = (syscall_handler_t *) sys_semtimedop, \ - [ __NR_fadvise64 ] = (syscall_handler_t *) sys_fadvise64, \ - [ 223 ] = (syscall_handler_t *) sys_ni_syscall, \ - [ __NR_utimes ] = (syscall_handler_t *) sys_utimes, \ - [ __NR_vserver ] = (syscall_handler_t *) sys_ni_syscall, \ [ 251 ] = (syscall_handler_t *) sys_ni_syscall, #define LAST_ARCH_SYSCALL 251 diff -puN
Re: [patch 1/6] DocBook: changes and extensions to the kernel documentation
Martin Waitz wrote:
--- linux-docbook.orig/drivers/video/fbmem.c 2005-04-06 12:13:12.674832161 +0200
+++ linux-docbook/drivers/video/fbmem.c 2005-04-06 12:24:11.946113964 +0200
@@ -1257,6 +1257,8 @@ int fb_new_modelist(struct fb_info *info
static char *video_options[FB_MAX];
static int ofonly;
+extern const char *global_mode_option;
+
/**
* fb_get_options - get kernel boot parameters
* @name: framebuffer name as it would appear in
@@ -1297,9 +1299,6 @@ int fb_get_options(char *name, char **op
return retval;
}
-
-extern const char *global_mode_option;
-
/**
* video_setup - process command line options
* @options: string of options
Index: linux-docbook/include/linux/skbuff.h
===
--- linux-docbook.orig/include/linux/skbuff.h 2005-04-06 12:13:12.677831708 +0200
+++ linux-docbook/include/linux/skbuff.h 2005-04-06 12:24:11.954112753 +0200
@@ -974,6 +974,7 @@ static inline void __skb_queue_purge(str
kfree_skb(skb);
}
+#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
/**
* __dev_alloc_skb - allocate an skbuff for sending
* @length: length to allocate
@@ -986,7 +987,6 @@ static inline void __skb_queue_purge(str
*
* %NULL is returned in there is no free memory.
*/
-#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
static inline struct sk_buff *__dev_alloc_skb(unsigned int length,
int gfp_mask)
{
Index: linux-docbook/mm/vmalloc.c
===
--- linux-docbook.orig/mm/vmalloc.c 2005-04-06 12:13:12.680831254 +0200
+++ linux-docbook/mm/vmalloc.c 2005-04-06 12:24:11.963111391 +0200
@@ -475,6 +475,10 @@ void *vmalloc(unsigned long size)
EXPORT_SYMBOL(vmalloc);
+#ifndef PAGE_KERNEL_EXEC
+# define PAGE_KERNEL_EXEC PAGE_KERNEL
+#endif
+
/**
* vmalloc_exec - allocate virtually contiguous, executable memory
*
@@ -488,10 +492,6 @@ EXPORT_SYMBOL(vmalloc);
* use __vmalloc() instead.
*/
-#ifndef PAGE_KERNEL_EXEC
-# define PAGE_KERNEL_EXEC PAGE_KERNEL
-#endif
-
void *vmalloc_exec(unsigned long size)
{
return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL_EXEC);
Although these patches do nothing but move code above a comment block,
they make me worry/grumble, because the author clearly preferred the
original code layout.
I'm -not- going to NAK this changeset, since it's not my code, but just
pointing this out. It would be nice if kernel-doc could grok this sort
of stuff, but I understand why it can't (without parsing c/cpp).
ACK for the other changesets in your series.
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/
Fwd: [uml-devel] [UML/2.6] -bk7 tree does not run when compiled as SKAS-only
Andrew, could you please put this in your -rc regressions folder? Thanks. -- Forwarded Message -- Subject: [uml-devel] [UML/2.6] -bk7 tree does not run when compiled as SKAS-only Date: Tuesday 22 March 2005 18:32 From: Blaisorblade <[EMAIL PROTECTED]> To: Jeff Dike <[EMAIL PROTECTED]>, Bodo Stroesser <[EMAIL PROTECTED]> Cc: user-mode-linux-devel@lists.sourceforge.net Just verified that without TT mode enabled, 2.6.11-bk7 tree compiles (when CONFIG_SYSCALL_DEBUG is disabled) but does not run if when compiled TT mode was disabled. I've verified this with a clean compile (I had this doubt), both with static link enabled and disabled. Sample output: ./vmlinux ubd0=~/Uml/toms.rootfs Checking for /proc/mm...found Checking for the skas3 patch in the host...found Checking PROT_EXEC mmap in /tmp...OK [end of output] 2.6.11 works in the same situation (both with static link enabled and disabled). I'm investigating but busy with other stuff, however there are not many patches which went in for this release. Jeff, any ideas? -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882_id=15148=click ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel --- -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade - 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: [uml-devel] [linux-2.6-bk] UML compile broken!
On Wednesday 06 April 2005 15:16, Anton Altaparmakov wrote: > Uml compile is btoken in current linus bk 2.6: > > CC arch/um/kernel/ptrace.o > arch/um/kernel/ptrace.c: In function `send_sigtrap': > arch/um/kernel/ptrace.c:324: warning: implicit declaration of function > `SC_IP' > arch/um/kernel/ptrace.c:324: error: union has no member named `tt' > arch/um/kernel/ptrace.c:324: error: union has no member named `tt' > arch/um/kernel/ptrace.c:324: error: invalid lvalue in unary `&' > make[1]: *** [arch/um/kernel/ptrace.o] Error 1 > make: *** [arch/um/kernel] Error 2 > > My .config is attached. I suspect it is because I am not compiling in > TT support and only SKAS... Well, good guess - you're getting more and more used with UML! Yes, the fix is in -mm. Quoting from -rc2-mm1 announce: +uml-fix-compilation-for-__choose_mode-addition.patch UML fix Andrew, can you merge it now, if you want, after Anton verifies it's the correct fix indeed for his problem? I *do* expect his situation to fail without the patch, but just to be more sure. However, I recall with 2.6.11-bk7 a slightly different problem, when compiling only SKAS mode in, and I don't think this has been fixed: [uml-devel] [UML/2.6] -bk7 tree does not run when compiled as SKAS-only I'm forwarding that mail to LKML and you, Andrew - for your -rc regressions mail folder. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade - 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/
Light Scribe Technology
Hi all, Can you tell me if there is currently support in the kernel for HP's new LightScribe technology? (http://h30015.www3.hp.com/hp_dec/lightscribe/index_FL.asp). If there is not, are there plans for it? Supposdly, you can burn DVD's or CD's, then flip the media over and burn a label directly onto the CD or DVD (no ink or toner...the laser burns it directly onto the CD) Thanks Alan __ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest - 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-pm] Re: [RFC] Driver States
On Tue, 2005-04-05 at 11:24 +0200, Pavel Machek wrote: > Hi! > > > > You have a few things here that can easily conflict, and that will be > > > developed at different paces. I like the direction that it's going, but > > > how do you intend to do it gradually. I.e. what to do first? > > > > I think the first step would be for us to all agree on a design, whether > > it be this one or another, so we can began planning for long term > > changes. > > > > My arguments for these changes are as follows: > > 0. I do not see how to gradually roll this in. > > > 4. Having responsibilities at each driver level encourages a > > layered and object based design, reducing code duplication and > > complexity. > > Unfortunately, you'll be retrofiting this to existing drivers. AFAICS, > trying to force existing driver to "layered and object based design" > can only result in mess. > Pavel Fair enough. How does this sound? I'd like to add "*attach" and "*detach" to "struct device_driver". These functions would act as one time initializers and decontructors. Then we could rename "*probe" to "*start", and "*remove" to "*stop", which should be rather trivial to fix up. From there drivers could slowly be converted to use "*attach" and "*detach", but will not be broken along the way. So the basic flow would be like this: 1.) a driver is bound to a device 2.) *attach is called to allocate data structures 3.) *start when it's time to probe the device 4.) *stop when the user disables the device 5.) repeat steps 3 and 4 any number of times 6.) *detach is called when unbinding the driver The driver layering stuff could come later, but just implementing these specific components would have immediate benefits. In this early stage in development, I'd like to at least be able to start and stop drivers for reasons outside of power management (ex. user preference or resource re-balancing). If a "*resume" function can also utilize this functionality, then all the better. Thanks, Adam - 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: Kernel SCM saga..
On Apr 6, 2005 3:24 PM, Matan Peled <[EMAIL PROTECTED]> wrote: > Jon Smirl wrote: > > ODSL could then GPL the code and quiet the > > critics. > > And also cause aaid GPL'ed code to be immediatly ported over to Windows. I > don't > think BitMover could ever agree to that. Windows Bitkeeper licenses are not that expensive, wouldn't you rather keep your source in a licensed supported version? Who is going to do this backport, then support it and track new releases? Why do people pay for RHEL when they can get it for free? They want support and a guarantee that their data won't be lost. Even with a GPL'd Linux Bitkeeper I'll bet half of the existing Linux paying customers will continue to use a paid version. There is a large difference in the behavior of corporations with huge source bases and college students with no money. The corporations will pay to have someone responsible for ensuring that the product works. -- Jon Smirl [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: klists and struct device semaphores
On Wed, 6 Apr 2005, Patrick Mochel wrote: > > Third, why does device_release_driver() call klist_del() instead of > > klist_remove() for dev->knode_driver? Is that just a simple mistake? > > The klist_node doesn't seem to get unlinked anywhere. > > It can be called from driver_for_each_device() when the driver has been > unloaded. Since that increments the reference count for the node when it's > unregistering it, klist_remove() will deadlock. Instead klist_del() is > called, and when the next node is grabbed, that one will be let go and > removed from the list. The patch looks good. But isn't there still a problem with device_release_driver()? It doesn't wait for the klist_node to be removed from the klist before unlocking the device and moving on. As a result, if another driver was waiting to bind to the device you would corrupt the list pointers, by calling klist_add_tail() for the new driver before klist_release() had run for the old driver. I'll be interested to see how you manage to solve this. The only way I can think of is to avoid using driver_for_each_device() in driver_detach(). Alan Stern - 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: Kernel SCM saga..
Replying to Linus Torvalds: > Ok, > as a number of people are already aware (and in some cases have been Actually, I'm very disappointed things gone such counter-productive way. All along the history, I was against Larry's opponents, but at the end, they are right. That's pity. To quote vin diesel' character Riddick, "there's no such word as friend", or something. Anyway, seems that folks in Canonical was aware about it, and here's the result of this awareness: http://bazaar-ng.org/ This need some testing though, along with really hard part - transfer all history, nonlinear ... I don't know how anyone can do this till 1 Jul 2005, sorry :( > PS. Don't bother telling me about subversion. If you must, start reading > up on "monotone". That seems to be the most viable alternative, but don't > pester the developers so much that they don't get any work done. They are > already aware of my problems ;) Monotone is good, but I don't really know limits of sqlite3 wrt kernel case. And again, what we need to do to retain history ... -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head - 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 1/6]SEP initialization rework
hoi :) On Mon, Apr 04, 2005 at 10:05:56AM +0800, Li Shaohua wrote: > - on_each_cpu(enable_sep_cpu, NULL, 1, 1); with this on_each_cpu call gone, you should also be able to remove the useless info pointer in enable_sep_cpu. -- Martin Waitz signature.asc Description: Digital signature
Out of memory with Java 1.5 and 2.6.11.6
I see regular crashes with 2.6.11.6 (mandrake-patched) and Java 1.5.02 (01 too btw, but not 1.4.2). Gentoo people report the same problem sugesting that it may have appeared between 2.6.11.4 and 2.6.11.5. If I start eclipse and then, outside of eclipse, starts a java 1.5 process eclipse dies instantly. Not always, but usually when I stop watching. Any clues? -- robin oh, here is an excerpt from /var/log/messages. Apr 5 22:05:20 xine kernel: oom-killer: gfp_mask=0xd0 Apr 5 22:05:20 xine kernel: DMA per-cpu: Apr 5 22:05:20 xine kernel: cpu 0 hot: low 2, high 6, batch 1 Apr 5 22:05:20 xine kernel: cpu 0 cold: low 0, high 2, batch 1 Apr 5 22:05:20 xine kernel: Normal per-cpu: Apr 5 22:05:20 xine kernel: cpu 0 hot: low 32, high 96, batch 16 Apr 5 22:05:20 xine kernel: cpu 0 cold: low 0, high 32, batch 16 Apr 5 22:05:20 xine kernel: HighMem per-cpu: empty Apr 5 22:05:20 xine kernel: Apr 5 22:05:20 xine kernel: Free pages:5684kB (0kB HighMem) Apr 5 22:05:20 xine kernel: Active:107335 inactive:5929 dirty:0 writeback:4 unstable:0 free:1421 slab:9726 mapped:113240 pagetables:1705 Apr 5 22:05:20 xine kernel: DMA free:2068kB min:88kB low:108kB high:132kB active:8392kB inactive:0kB present:16384kB pages_scanned:8802 all_unreclaimable? yes Apr 5 22:05:20 xine kernel: lowmem_reserve[]: 0 495 495 Apr 5 22:05:21 xine kernel: Normal free:3616kB min:2800kB low:3500kB high:4200kB active:420948kB inactive:23716kB present:507576kB pages_scanned:0 all_unreclaimable? no Apr 5 22:05:21 xine kernel: lowmem_reserve[]: 0 0 0 Apr 5 22:05:21 xine kernel: HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no Apr 5 22:05:21 xine kernel: lowmem_reserve[]: 0 0 0 Apr 5 22:05:21 xine kernel: DMA: 1*4kB 0*8kB 1*16kB 0*32kB 2*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2068kB Apr 5 22:05:21 xine kernel: Normal: 208*4kB 8*8kB 2*16kB 6*32kB 7*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 3616kB Apr 5 22:05:21 xine kernel: HighMem: empty Apr 5 22:05:21 xine kernel: Swap cache: add 1267612, delete 1246233, find 7825455/7951372, race 0+6 Apr 5 22:05:21 xine kernel: Free swap = 760276kB Apr 5 22:05:21 xine kernel: Total swap = 1060248kB Apr 5 22:05:21 xine kernel: Out of Memory: Killed process 23770 (java). - 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: [08/08] uml: va_copy fix
On Wed, 6 April 2005 21:09:50 +0200, Blaisorblade wrote:
>
> I'm reattaching the patch, so that you can look at the changelog (I'm also
> resending it as a separate email so that it is reviewed and possibly merged).
> Basically this is an error in GCC 2 and not in GCC 3:
>
> int [] list = {
> [0] = 1,
> [0] = 1
> }
> (I've not tested the above itself, but this should be a stripped down version
> of one of the bugs fixed in the patch).
>
> That sort of code in the UML syscall table is not the safer one - in fact,
> apart this patch for the stable tree, I'm refactoring the UML syscall table
> completely (for 2.6.12 / 2.6.13).
>
> Btw: I've not investigated which one of the two behaviours is the buggy one -
> if you know, maybe you or I can report it.
Your code is at best redundant. And I'd bet beer that it is not what
its author intended to write. So the bug is in GCC 3, imo.
Jörn
--
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown
-
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: Kernel SCM saga..
Jon Smirl wrote: > ODSL could then GPL the code and quiet the > critics. And also cause aaid GPL'ed code to be immediatly ported over to Windows. I don't think BitMover could ever agree to that. -- [Name ] :: [Matan I. Peled] [Location ] :: [Israel] [Public Key] :: [0xD6F42CA5] [Keyserver ] :: [keyserver.kjsl.com] encrypted/signed plain text preferred signature.asc Description: OpenPGP digital signature
Re: [PATCH 2.6.11.6 1/6] irq and pci_ids: patch for Intel ESB2
Hello, Do I also need to create and submit these patches for 2.6.12-rc2 in order to get them into 2.6.12 or will these make it into 2.6.12 as is? Thanks, Jason Gaston On Tuesday 05 April 2005 08:00, Jason Gaston wrote: > Hello, > > This patch adds the Intel ESB2 DID's to the irq.c and pci_ids.h files. This > patch was built against the 2.6.11.6 kernel. > If acceptable, please apply. > > Thanks, > > Jason Gaston > > Signed-off-by: Jason Gaston <[EMAIL PROTECTED]> > > --- linux-2.6.11.6/arch/i386/pci/irq.c.orig 2005-03-28 08:44:26.350888632 > -0800 > +++ linux-2.6.11.6/arch/i386/pci/irq.c2005-03-28 08:49:38.961364616 > -0800 > @@ -495,6 +495,7 @@ > case PCI_DEVICE_ID_INTEL_ICH6_1: > case PCI_DEVICE_ID_INTEL_ICH7_0: > case PCI_DEVICE_ID_INTEL_ICH7_1: > + case PCI_DEVICE_ID_INTEL_ESB2_0: > r->name = "PIIX/ICH"; > r->get = pirq_piix_get; > r->set = pirq_piix_set; > --- linux-2.6.11.6/include/linux/pci_ids.h.orig 2005-03-28 > 09:09:51.343054584 -0800 > +++ linux-2.6.11.6/include/linux/pci_ids.h2005-03-28 09:29:16.883865448 > -0800 > @@ -2260,6 +2260,25 @@ > #define PCI_DEVICE_ID_INTEL_ICH6_17 0x266d > #define PCI_DEVICE_ID_INTEL_ICH6_18 0x266e > #define PCI_DEVICE_ID_INTEL_ICH6_19 0x266f > +#define PCI_DEVICE_ID_INTEL_ESB2_0 0x2670 > +#define PCI_DEVICE_ID_INTEL_ESB2_1 0x2680 > +#define PCI_DEVICE_ID_INTEL_ESB2_2 0x2681 > +#define PCI_DEVICE_ID_INTEL_ESB2_3 0x2682 > +#define PCI_DEVICE_ID_INTEL_ESB2_4 0x2683 > +#define PCI_DEVICE_ID_INTEL_ESB2_5 0x2688 > +#define PCI_DEVICE_ID_INTEL_ESB2_6 0x2689 > +#define PCI_DEVICE_ID_INTEL_ESB2_7 0x268a > +#define PCI_DEVICE_ID_INTEL_ESB2_8 0x268b > +#define PCI_DEVICE_ID_INTEL_ESB2_9 0x268c > +#define PCI_DEVICE_ID_INTEL_ESB2_10 0x2690 > +#define PCI_DEVICE_ID_INTEL_ESB2_11 0x2692 > +#define PCI_DEVICE_ID_INTEL_ESB2_12 0x2694 > +#define PCI_DEVICE_ID_INTEL_ESB2_13 0x2696 > +#define PCI_DEVICE_ID_INTEL_ESB2_14 0x2698 > +#define PCI_DEVICE_ID_INTEL_ESB2_15 0x2699 > +#define PCI_DEVICE_ID_INTEL_ESB2_16 0x269a > +#define PCI_DEVICE_ID_INTEL_ESB2_17 0x269b > +#define PCI_DEVICE_ID_INTEL_ESB2_18 0x269e > #define PCI_DEVICE_ID_INTEL_ICH7_0 0x27b8 > #define PCI_DEVICE_ID_INTEL_ICH7_1 0x27b1 > #define PCI_DEVICE_ID_INTEL_ICH7_2 0x27c0 > @@ -2285,6 +2304,18 @@ > #define PCI_DEVICE_ID_INTEL_ICH7_22 0x27e0 > #define PCI_DEVICE_ID_INTEL_ICH7_23 0x27e2 > #define PCI_DEVICE_ID_INTEL_82855PM_HB 0x3340 > +#define PCI_DEVICE_ID_INTEL_ESB2_19 0x3500 > +#define PCI_DEVICE_ID_INTEL_ESB2_20 0x3501 > +#define PCI_DEVICE_ID_INTEL_ESB2_21 0x3504 > +#define PCI_DEVICE_ID_INTEL_ESB2_22 0x3505 > +#define PCI_DEVICE_ID_INTEL_ESB2_23 0x350c > +#define PCI_DEVICE_ID_INTEL_ESB2_24 0x350d > +#define PCI_DEVICE_ID_INTEL_ESB2_25 0x3510 > +#define PCI_DEVICE_ID_INTEL_ESB2_26 0x3511 > +#define PCI_DEVICE_ID_INTEL_ESB2_27 0x3514 > +#define PCI_DEVICE_ID_INTEL_ESB2_28 0x3515 > +#define PCI_DEVICE_ID_INTEL_ESB2_29 0x3518 > +#define PCI_DEVICE_ID_INTEL_ESB2_30 0x3519 > #define PCI_DEVICE_ID_INTEL_82830_HB 0x3575 > #define PCI_DEVICE_ID_INTEL_82830_CGC0x3577 > #define PCI_DEVICE_ID_INTEL_82855GM_HB 0x3580 > - 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/
