Re: [BK] upgrade will be needed
On Thu, February 17, 2005 8:42 pm, Horst von Brand said: > Linus clearly considered not just his /own/ workflow, but the workflow > for the /whole/ kernel development community. In fact, BK was designed Well, the /whole/ community isn't yet included, that's what we're talking about. > around the requirements Linus and other head hackers laid down for a > SCM for use in Linux. And I'm quite sure that if Linus et al had > serious misgivings about the license somehow hindering Linux > development, they would have got it fixed or dumped BK. Linus has > said time and again that he just cares for the very best kernel > possible, nothing else. Do you think that the developers who must or want to use other SCM tools desire less? > Sure, from the periphery of kernel development using something else looks > simple. But you have to consider there are literaly dozens of trees (of > the head maintainers) exchanging changesets. The flow of going into > 2.6 is astonishing right now, I'd say some 3 or 5 times more than > what got into the most furious 2.3 patch frenzies. Existing open > source tools just aren't up to the task, as Linus has repeatedly said. There are ways that the tools could coexist and work together better than they do today. If people would stop acting like BK was in jeopardy of being taken away from them and realize that others just want the ability to use their tools of choice too. > Just now there are starting to be halfways useful SCM systems (almost > all based on the "one central repository" idea, which doesn't cut it > for Linux), but they aren't proven enough. Yeah, there are some glimmers of hope for sure, but you're right they're a ways off. Sean - 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/
Kernel hangs on PCI config register access ???
Hi,
we have a bunch of systems which semi-reproducibly (chance of 1:1000) hang
when a PCMCIA card is removed from its PCI->PCMCIA interface via "cardctl
eject". Right *here*, in fact:
static int pci_conf1_read (int seg, int bus, int devfn, int reg, int
len, + u32 *value) {
[...]
case 2:
debug("you see me \n");
*value = inw(0xCFC + (reg & 2));
debug("but you don't get here \n");
break;
[...]
Does anybody have *any* idea what could possibly be the cause of this?
Using pci=bios still hangs; pci=conf2 doesn't work.
FWIW, the call sequence is:
shutdown_socket
yenta_sock_init
yenta_clear_maps
yenta_set_socket
pci_bus_read_config_word
pci_conf1_read
The systems in question are wildly different (VIA vs. Intel CPUs, standard
mainboard vs. PCI backplane, Ricoh vs. ENE cardbus bridges), so I'm
inclined to rule out hardware problems. The NMI monitor doesn't trigger
(yes I tested it), kgdb is unresponsive -- the system hangs hard at that
point, as far as I can determine.
Kernel: tested with various 2.6.1? plus -rc* and/or -mm*, no change.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [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: [BK] upgrade will be needed
On Thu, February 17, 2005 11:00 pm, Theodore Ts'o said: > If you think that, you truly do not understand the value of BK, and > why Linus chose it. Hey Ted, No, I just disagree that it was an absolute requirement or worth its cost that so many want to completely discount. Andrew has pretty much shown BK is not required, he's still using patches. Cheers, Sean - 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: [Fastboot] Re: [PATCH] /proc/cpumem
Itsuro Oda <[EMAIL PROTECTED]> writes: > I see. I would like to contribute as possible I can. Pick some piece you that have an affinity for and work on it. Problems are best solved by those who see them and by those who care :) I believe Vivek Goyal is currently working on the remaining user space piece, and expects to have something in a week or so. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Current bk on ppc32: kernel text corruption
Ok, we may not be over with memory corruption bugs yet. ppc64 now seem stable running LTP overnight, but my laptop has a page of kernel .text replaced with zero's as soon as I launch X (and just X, no need to launc the whole desktop environment). I suspect remap_pfn_range() but I haven't checked yet. 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: cdrecord stuck in D state with USB DVD burner
On Friday 18 February 2005 02:21, Chuck Berg wrote: > I have a system with two USB DVD burners. If I burn a disc on both at the > same time, one of the dvdrecord processes hangs (unkillably stuck in the > D state). The usb-storage kernel thread was also stuck in the D state. > > I power-cycled both burners. The disconnect appeared in the logs but > they were not detected when I powered them back on. After this, khubd > and scsi_eh_12 kernel threads were stuck in the D state. > > This is with kernel 2.6.11-rc4. Fedora's 2.6.10-1.766_FC3smp also has the > same problem. > > This is repeatable. I have no trouble if I only write to one drive at a time. I used to send this to LKML periodically: Sending bug report/patch: = * Some device drivers have active developers, try to contact them first. * Otherwise find a subsystem maintainer to which your report pertains and send report to his address. * Small fixes and device driver updates are best directed to subsystem maintainers and "small bits" integrators. * It never hurts to CC: Linux kernel mailing list, but without specific maintainer address in To: field there is high probability that your patch won't be noticed. You have been warned. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] Re: [PATCH] /proc/cpumem
Hi, On 17 Feb 2005 02:55:31 -0700 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > My role in this is that of maintainer and architect. On a practical > level I gain nothing from a working crash-dump/kexec-on-panic > implementation except it stops being a gating factor for the rest > of the kexec code. So while many times I can see what needs to be > done it is hard for me to justify doing it. So a lot of times > where I will weigh in with code is when I see a particular blind spot > on the part of the implementors. I see. I would like to contribute as possible I can. Thanks. -- Itsuro ODA <[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] Consolidate compat_sys_waitid
On Tue, 15 Feb 2005 18:43:07 + Matthew Wilcox <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 15, 2005 at 02:01:49PM +1100, Stephen Rothwell wrote: > > > +asmlinkage long compat_sys_waitid(u32 which, u32 pid, > > + struct compat_siginfo __user *uinfo, u32 options, > > + struct compat_rusage __user *uru) > > Some subtle differences which I feel incompetent to diagnose ... ours > looks like: > > asmlinkage int compat_sys_waitid(int which, pid_t pid, > compat_siginfo_t __user *infop, int options, > struct compat_rusage __user *ru) They are u32 in my version because we decided that the kernel zero extends the compat syscall parameters. > Other than variable names, we're identical to this point: > > /* Tell copy_siginfo_to_user that it was __SI_CHLD */ > ksiginfo.si_code |= __SI_CHLD; > > if (compat_copy_siginfo_to_user(infop, &ksiginfo) != 0) Every other relevant architecture has copy_siginfo_to_user32 which returns 0/-EFAULT. And it is declared in linux/compat.h. I like your name better, but that is a different patch. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ - 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/
Possible bug in the Linux 2.4.29 e1000 driver
Hi, There seems to be a bug in the Linux 2.4.29 e1000 driver. With an SMP kernel on a single Intel 3.0GHZ HT cpu, and an 82547 NIC in half-duplex 100Mb/s mode, the kernel with lock up hard (no nmi_watchdog=1 messages) under reasonably heavy transmit network loads. The bug does not manifest itself with a non SMP kernel, and does not appear to be there in full duplex mode on a fully switched network. Using the e1000 driver from 2.4.28 or the latest 5.7.6 driver seems to fix the problem. I guess merging the latest driver would be a good idea. The 5.7.6 driver is available from: http://sourceforge.net/project/showfiles.php?group_id=42302&package_id=54835 I'm using an Abit p4c800-E Deluxe m/b, and have verified this is reproducible on similar machine with the same m/b. Cheers, ===Rich lspci -vv 02:01.0 Ethernet controller: Intel Corp. 82547EI Gigabit Ethernet Controller (LOM) Subsystem: Asustek Computer, Inc.: Unknown device 80f7 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- SERR-Latency: 0 (63750ns min), cache line size 04 Interrupt: pin A routed to IRQ 18 Region 0: Memory at fe9e (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at cf80 [size=32] Capabilities: cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping: 9 cpu MHz : 2998.594 cache size : 512 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 pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid bogomips: 5989.99 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping: 9 cpu MHz : 2998.594 cache size : 512 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 pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid bogomips: 5989.99 cat /proc/interrupts CPU0 CPU1 0: 737790 0IO-APIC-edge timer 1: 2 0IO-APIC-edge keyboard 8: 1 0IO-APIC-edge rtc 9: 0 0 IO-APIC-level acpi 14: 3767 1IO-APIC-edge ide0 15: 15 0IO-APIC-edge ide1 16: 25 0 IO-APIC-level usb-uhci, usb-uhci 17: 0 0 IO-APIC-level Intel ICH5 18: 4316 0 IO-APIC-level eth0, usb-uhci 19: 0 0 IO-APIC-level usb-uhci 20: 2 0 IO-APIC-level ohci1394 23: 0 0 IO-APIC-level ehci_hcd NMI: 737722 737722 LOC: 737723 737727 ERR: 0 MIS: 0 uname -a Linux p4-3gig 2.4.29 #1 SMP Tue Feb 15 16:40:54 GMT 2005 i686 unknown unknown GNU/Linux - 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] Sparse Memory Handling (hot-add foundation)
On Thu, Feb 17, 2005 at 04:03:53PM -0800, Dave Hansen wrote: > The attached patch Just tried to compile this and noticed that there is no definition of valid_section_nr(), referenced in sparse_init. -- 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/
le conversion of posix acl fields
I saw your patch referenced in http://marc.theaimsgroup.com/?l=linux-kernel&m=110859724430665&w=2 At first glance there is one odd place in the proposed patch: - cifs_ace->cifs_e_perm = (__u8)cpu_to_le16(local_ace->e_perm); - cifs_ace->cifs_e_tag = (__u8)cpu_to_le16(local_ace->e_tag); + cifs_ace->cifs_e_perm = (__u8)le16_to_cpu(local_ace->e_perm); + cifs_ace->cifs_e_tag = (__u8)le16_to_cpu(local_ace->e_tag); If the field is le already then we should not convert it to cpu (since cifs protocol assumes le format on the wire - it probably needs no endian conversion in these two lines unless I am missing something) - 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: [BK] upgrade will be needed
"Sean" <[EMAIL PROTECTED]> said: > On Thu, February 17, 2005 3:52 pm, Horst von Brand said: [...] > > "Best tool for the job" certainly includes minutiae like "benefits" and > > "price". > Thank you, that's my point. It's not just about the geeky microscopic > technical details. Linus clearly considered not just his /own/ workflow, but the workflow for the /whole/ kernel development community. In fact, BK was designed around the requirements Linus and other head hackers laid down for a SCM for use in Linux. And I'm quite sure that if Linus et al had serious misgivings about the license somehow hindering Linux development, they would have got it fixed or dumped BK. Linus has said time and again that he just cares for the very best kernel possible, nothing else. Sure, from the periphery of kernel development using something else looks simple. But you have to consider there are literaly dozens of trees (of the head maintainers) exchanging changesets. The flow of going into 2.6 is astonishing right now, I'd say some 3 or 5 times more than what got into the most furious 2.3 patch frenzies. Existing open source tools just aren't up to the task, as Linus has repeatedly said. Just now there are starting to be halfways useful SCM systems (almost all based on the "one central repository" idea, which doesn't cut it for Linux), but they aren't proven enough. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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: [BK] upgrade will be needed
Clemens Schwaighofer <[EMAIL PROTECTED]> said: > On 02/17/2005 01:57 PM, Theodore Ts'o wrote: > > Compare the number of developers, the number of overlapping > > simultaneous development trees, and the number of patches that touch > > overlapping files, and you'll begin to start to appreciate the > > difference between a system that can work for Linux, and a system that > > can working for simpler projects. > apache might be simpler, but I doubt that for gcc. But well lets see > what the gcc guys will decide. gcc has very much less developers than the kernel. It has worked for years around CVS' shortcommings, plus being a core GNU package, it is quite unlikely to /ever/ go for a non-oss SCM. Plus the bureaucracy (have to have a paper signing over ownership to the FSF for any changes) make a fully Linux-style development unlikely (and thus BK (which was designed as SCM for the kernel) not really useful). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2005 01:00 PM, Theodore Ts'o wrote: > On Thu, Feb 17, 2005 at 06:32:04PM -0500, Sean wrote: > >>No. It's about recognizing the needs of more people than just the few at >>the top. Besides, with a free tool at the Head, bk could continue to be >>used underneath by Linus and anyone else. > > > If you think that, you truly do not understand the value of BK, and > why Linus chose it. He choose it because it was the best tool to do the job at that time. It might still be the best job to do it. But for a normal user, who just wants to check out certain bk pulls, the new license is not bearable. I think we need a SVN mirror here soon, very soon. - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCFWkcjBz/yQjBxz8RAm5IAKDERXzaCeh1Qcuipp3sjZXxC7/DwgCgpl63 YgVM09sYczPMJsedObgKkLI= =8vFK -END PGP SIGNATURE- - 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: [BK] upgrade will be needed
On Thu, Feb 17, 2005 at 06:32:04PM -0500, Sean wrote: > No. It's about recognizing the needs of more people than just the few at > the top. Besides, with a free tool at the Head, bk could continue to be > used underneath by Linus and anyone else. If you think that, you truly do not understand the value of BK, and why Linus chose it. - Ted - 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] add umask parameter to procfs
On Fri, Feb 18, 2005 at 04:22:49AM +0100, Bodo Eggert wrote: > Herbert Poetzl <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote: > >> Rene Scharfe <[EMAIL PROTECTED]> wrote: > > >> > Add proc.umask kernel parameter. It can be used to restrict permissions > >> > on the numerical directories in the root of a proc filesystem, i.e. the > >> > directories containing process specific information. > >> > > >> > E.g. add proc.umask=077 to your kernel command line and all users except > >> > root can only see their own process details (like command line > >> > parameters) with ps or top. It can be useful to add a bit of privacy to > >> > multi-user servers. > > >> The feature seems fairly obscure, although very simple. > >> Is anyone actually likely to use this? > > I'm using a openwall-patched kernel on some of my boxes with a similar > feature. I did not yet test this patch, but I like it. It's cheap, and > it fixes a potential security leak. don't get me wrong, I'm all for something like this, as a matter of fact we are using something more specialized for linux-vserver to hide processes between contexts ... > > what about parents (and especially the init process) > > some tools like pstree (or ps in certain cases) depend > > on their visibility/accessability ... > > pstree will break if /proc/1 isn't readable, unless you specify a readable > starting pid. Since this is not the default case, this is IMO ok. (It should > be easy to rewrite it to trace the ppid-chains like "ps auxf" already does > correctly, or rather implement it in ps where it belongs). hmm, so what about debugger and similar not able to find the parent process or something like that? I'd say this needs some more investigation what tools and applications will break once it is enabled ... > None of my other tools seemed to stop working in an unintended way, but I > don't usurally spend my time watching processes. > > Sample output of "ps auxf" on a openwall-patched system: > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > 7eggert 22504 5.0 3.5 2800 1608 pts/4S04:14 0:00 -bash > 7eggert 22522 0.0 1.7 2856 792 pts/4R04:14 0:00 \_ ps auxf > 7eggert 22483 2.3 3.4 2800 1588 pts/2S04:14 0:00 -bash > > > what if you want to change it afterwards (when tools > > did break)? > > Change the kernel command line back and reboot (or reload the module). hmm, reload the procfs module? not very likely ;) best, Herbert - 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: Please open sysfs symbols to proprietary modules
[EMAIL PROTECTED] wrote: On Thu, 03 Feb 2005 09:41:00 +0100, Arjan van de Ven <[EMAIL PROTECTED]> wrote: I suggest you talk to a lawyer and review the general comments about binary modules with him (http://people.redhat.com/arjanv/COPYING.modules for example). You are writing an addition to linux from scratch, and it is generally not considered OK to do that in binary form (I certainly do not consider it OK). So what about companies like ImageStream who write proprietary Linux network drivers for their hardware from scratch with no previous ports from another OS? Obviously he doesn't consider that to be okay, and those companies are taking a risk that someone will take legal action against them. 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: [PATCH] add umask parameter to procfs
Herbert Poetzl <[EMAIL PROTECTED]> wrote: > On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote: >> Rene Scharfe <[EMAIL PROTECTED]> wrote: >> > Add proc.umask kernel parameter. It can be used to restrict permissions >> > on the numerical directories in the root of a proc filesystem, i.e. the >> > directories containing process specific information. >> > >> > E.g. add proc.umask=077 to your kernel command line and all users except >> > root can only see their own process details (like command line >> > parameters) with ps or top. It can be useful to add a bit of privacy to >> > multi-user servers. >> The feature seems fairly obscure, although very simple. >> Is anyone actually likely to use this? I'm using a openwall-patched kernel on some of my boxes with a similar feature. I did not yet test this patch, but I like it. It's cheap, and it fixes a potential security leak. > what about parents (and especially the init process) > some tools like pstree (or ps in certain cases) depend > on their visibility/accessability ... pstree will break if /proc/1 isn't readable, unless you specify a readable starting pid. Since this is not the default case, this is IMO ok. (It should be easy to rewrite it to trace the ppid-chains like "ps auxf" already does correctly, or rather implement it in ps where it belongs). None of my other tools seemed to stop working in an unintended way, but I don't usurally spend my time watching processes. Sample output of "ps auxf" on a openwall-patched system: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 7eggert 22504 5.0 3.5 2800 1608 pts/4S04:14 0:00 -bash 7eggert 22522 0.0 1.7 2856 792 pts/4R04:14 0:00 \_ ps auxf 7eggert 22483 2.3 3.4 2800 1588 pts/2S04:14 0:00 -bash > what if you want to change it afterwards (when tools > did break)? Change the kernel command line back and reboot (or reload the module). - 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: [darcs-users] Re: [BK] upgrade will be needed
On Thu, February 17, 2005 9:24 pm, Tupshin Harper said: Hi Tupshin, > Speaking as somebody that uses Darcs evey day, my opinion is that the > future of OSS SCM will be something like arch or darcs but that neither > are ready for projects the size of the linux kernel yet. Darcs is > definitely way too slow for really large projects (though great for > small to medium sized ones). Last I checked, Arch was still too slow in > some areas, though that might have changed in recent months. Also, many > people, me included, find the usability of arch to be from ideal. > > My hope and expectation is that Arch and Darcs will both improve their > performance, features, and usability and that in the not too distant > future both of them will be viable alternatives for large scale source > tree management. Falling into the same category probably is svk, although it's less mature than the options you cite. > The important thing for the health of the SCM ecosystem is that there be > ways to losslessly convert and interoperate between them as well as > between legacy/centralized systems such as CVS and SVN as well as with > BK. Amen. Thanks, Sean - 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: seccomp for 2.6.11-rc4
On Wed, Feb 16, 2005 at 06:25:03AM +0100, Herbert Poetzl wrote: > hmm, just an idea, but have you thought about using > an indirect syscall table for your purposes? > > current->syscall_table > > and have a table for every 'mode' you want to use ... That would add an additional level of indirection for every syscall (you'll have to potentially waste a cacheline to read the address of the syscall table). While my current approach is absolutely zero cost for the fast path on x86-64 and it's a mere s/movb/movw/ for x86 (i.e. zero for x86 too). Perahps I could even get away with a movb on x86 but frankly I didn't even try ;) My priority has been not to change the fast path at all, and clearly I have to add a bitflag to achieve that. And once I've the bitflag it's not worth it anymore to change the syscall table, and I can validate the syscall number right away (this avoid building arrays and other more complex stuff). > or maybe have a 'mask' for every syscall (in a > separate table) which describes the allowed 'modes' > > just because checking the syscall number in a loop > doesn't look very scaleable to me ... You're right about it being O(N) if you use it for all modes, but it's really O(1) since it's being used for mode 0 only, and the number of syscalls in mode 0 is fixed so it's O(1) and more important the number is so small that it's really like O(1) in practice too (and not only in math terms just because the number of syscalls in mode 0 is fixed ;). Each mode can implement the mask as it wishes, so if you were to allow hundred of syscalls in mode 1 then you'd better implement the check as a bitmask as you suggested and you can do that while implementing mode 1. But seccomp isn't designed to allow a ton of syscalls, so there can be tiny differences between mode 0/1/2 and they should all have very few syscalls, so I doubt it'd worth implementing the bitmask thingy right now. 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: [darcs-users] Re: [BK] upgrade will be needed
Patrick McFarland wrote: On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote: Something that unintentionally started a flamewar. Well, we just went through another round of 'BK sucks' and 'BK sucks, we need to switch to something else'. Sans the flamewar, are there any options? CVS and SVN are out because they do not support 'off server' branches (arch and darcs do). Darcs would probably be the best choice because its easy to use, and the darcs team almost has a working linux-kernel import script (originally designed to just test darcs with a huge repo, but provides a mostly working linux tree). So, without the flamewar, what is everyone's opinion on this? Speaking as somebody that uses Darcs evey day, my opinion is that the future of OSS SCM will be something like arch or darcs but that neither are ready for projects the size of the linux kernel yet. Darcs is definitely way too slow for really large projects (though great for small to medium sized ones). Last I checked, Arch was still too slow in some areas, though that might have changed in recent months. Also, many people, me included, find the usability of arch to be from ideal. My hope and expectation is that Arch and Darcs will both improve their performance, features, and usability and that in the not too distant future both of them will be viable alternatives for large scale source tree management. The important thing for the health of the SCM ecosystem is that there be ways to losslessly convert and interoperate between them as well as between legacy/centralized systems such as CVS and SVN as well as with BK. -Tupshin - 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: [BK] upgrade will be needed
On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote: > Something that unintentionally started a flamewar. Well, we just went through another round of 'BK sucks' and 'BK sucks, we need to switch to something else'. Sans the flamewar, are there any options? CVS and SVN are out because they do not support 'off server' branches (arch and darcs do). Darcs would probably be the best choice because its easy to use, and the darcs team almost has a working linux-kernel import script (originally designed to just test darcs with a huge repo, but provides a mostly working linux tree). So, without the flamewar, what is everyone's opinion on this? -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpAuhopI9PLP.pgp Description: PGP signature
Re: Swsusp, resume and kernel versions
On Thu, Feb 17, 2005 at 08:56:52PM +0100, Pavel Machek wrote: > > > Just remember you're doing the mkswap if you decide to rearrange your > > > partitions at all, or code a script smart enough to grep your swap > > > partitions out of your fstab. > > > > It could be a workaround. Still it will cause loss of unsaved work if > > I happen to load wrong kernel. Given that the code checking for swsusp > > image can be marked __init I don't understand the reasons gainst doing > > it. > > How do you know which partitions to check? swsusp gets it from resume= > parameter, > but if you do not have it compiled, you probably have wrong cmdline, too. In many cases, you might have added the resume= line to every kernel that's booted (eg, LILO's global append= parameter, or Debian GRUB's magic kopts gear). Alternately (or additionally), you could examine the signature when sys_swapon is called on a swap partition (though the code couldn't be __init then). These together I want to claim would catch many of these cases, and any effort to avoid severe filesystem corruption is a good thing. Bernard. -- Bernard Blackham - 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] add umask parameter to procfs
On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote: > Rene Scharfe <[EMAIL PROTECTED]> wrote: > > > > Add proc.umask kernel parameter. It can be used to restrict permissions > > on the numerical directories in the root of a proc filesystem, i.e. the > > directories containing process specific information. > > > > E.g. add proc.umask=077 to your kernel command line and all users except > > root can only see their own process details (like command line > > parameters) with ps or top. It can be useful to add a bit of privacy to > > multi-user servers. > > > > The patch has been inspired by a similar feature in GrSecurity. > > > > It could have also been implemented as a mount option to procfs, but at > > a higher cost and no apparent benefit -- changes to this umask are not > > supposed to happen very often. Actually, the previous incarnation of > > this patch was implemented as a half-assed mount option, but I didn't > > know then how easy it is to add a kernel parameter. > > The feature seems fairly obscure, although very simple. > Is anyone actually likely to use this? what about parents (and especially the init process) some tools like pstree (or ps in certain cases) depend on their visibility/accessability ... was this tested except for the trivial case where just plain everything is visible? what if you want to change it afterwards (when tools did break)? best, Herbert > > +static umode_t umask = 0; > > a) I think the above should be called proc_umask. > > b) You shouldn't initialise it. > > c) When adding a kernel parameter you should update >Documentation/kernel-parameters.txt > - > 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: -rc3 leaking NOT BIO [Was: Memory leak in 2.6.11-rc1?]
On Thu, 2005-02-17 at 05:00, Parag Warudkar wrote:
> On Wednesday 16 February 2005 06:52 pm, Andrew Morton wrote:
> > So it's probably an ndiswrapper bug?
> Andrew,
> It looks like it is a kernel bug triggered by NdisWrapper. Without
> NdisWrapper, and with just 8139too plus some light network activity the
> size-64 grew from ~ 1100 to 4500 overnight. Is this normal? I will keep it
> running to see where it goes.
>
> A question - is it safe to assume it is a kmalloc based leak? (I am thinking
> of tracking it down by using kprobes to insert a probe into __kmalloc and
> record the stack to see what is causing so many allocations.)
>
Last time I debugged something like this, I ended up adding dump_stack()
in kmem_cache_alloc() for the specific slab.
If you are really interested, you can try to get following jprobe
module working. (need to teach about kmem_cache_t structure to
get it to compile and export kallsyms_lookup_name() symbol etc).
Thanks,
Badari
#include
#include
#include
#include
MODULE_PARM_DESC(kmod, "\n");
int count = 0;
void fastcall inst_kmem_cache_alloc(kmem_cache_t *cachep, int flags)
{
if (cachep->objsize == 64) {
if (count++ == 100) {
dump_stack();
count = 0;
}
}
jprobe_return();
}
static char *fn_names[] = {
"kmem_cache_alloc",
};
static struct jprobe kmem_probes[] = {
{
.entry = (kprobe_opcode_t *) inst_kmem_cache_alloc,
.kp.addr=(kprobe_opcode_t *) 0,
}
};
#define MAX_KMEM_ROUTINE (sizeof(kmem_probes)/sizeof(struct kprobe))
/* installs the probes in the appropriate places */
static int init_kmods(void)
{
int i;
for (i = 0; i < MAX_KMEM_ROUTINE; i++) {
kmem_probes[i].kp.addr = kallsyms_lookup_name(fn_names[i]);
if (kmem_probes[i].kp.addr) {
printk("plant jprobe at name %s %p, handler addr %p\n",
fn_names[i], kmem_probes[i].kp.addr, kmem_probes[i].entry);
register_jprobe(&kmem_probes[i]);
}
}
return 0;
}
static void cleanup_kmods(void)
{
int i;
for (i = 0; i < MAX_KMEM_ROUTINE; i++) {
unregister_jprobe(&kmem_probes[i]);
}
}
module_init(init_kmods);
module_exit(cleanup_kmods);
MODULE_LICENSE("GPL");
run_init_process problem
We are trying boot compact flash in the kernel code the run_init_process(char *file_name) trying to executed but the kernel hanged regards govind _ Get married the quickest way on BharatMatrimony.com. http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 SMS ur Life Partner - 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.10: irq 12 nobody cared!
On Thu, 17 Feb 2005, Joshua Kwan wrote: > > What was the previous kernel you ran on that machine, just out of > > interest? If it hasn't happened before, it would be interesting to know > > when it started happening... > > It used to be running 2.4.27, where there was no evidence of such a bug > occurring. I'd rather not bother with trying to find out what's going on > if it'll require me to reboot with all sorts prerelease snapshots, since > this is my web server, mail server, etc... 2.4.x won't even report that condition. So if it's still working in 2.6.x, then you can probably pretty much assume that the problem was always there, but 2.4.x just never talked about it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.10: irq 12 nobody cared!
Linus Torvalds wrote: Does the box still work? It may well be that once all drivers have had a chance to initialize their hardware properly, the problem is just gone, and that the interim reports about not being able to handle the irq are just temporary noise. The box seems to work fine; on the other hand, I don't have a mouse or keyboard plugged in, it's my router machine. (In this particular instance, I had a keyboard plugged in after I realized I goofed up with some modules, but generally I don't do that.) Of course, even if it works, the noise _is_ actually indicative of a problem. There shouldn't be any pending interrupts, especially not level-triggered ones. And it can cause a non-working mouse if you don't load the driver for the wireless card (or vice versa). If I have to reboot the box for something, I'll experiment with plugging in a mouse before loading hostap. (But see below) What was the previous kernel you ran on that machine, just out of interest? If it hasn't happened before, it would be interesting to know when it started happening... It used to be running 2.4.27, where there was no evidence of such a bug occurring. I'd rather not bother with trying to find out what's going on if it'll require me to reboot with all sorts prerelease snapshots, since this is my web server, mail server, etc... -- Joshua Kwan signature.asc Description: OpenPGP digital signature
Re: 2.6.10: irq 12 nobody cared!
On Wed, 16 Feb 2005, Joshua Kwan wrote: > > Just migrated to 2.6.10 on an old VIA MVP3 box and I'm getting this: > > irq 12: nobody cared! IRQ 12 should be your PS/2 mouse irq too. It seems your wireless card shares that interrupt, which is unusual, but not necessarily wrong. My guess is that the wireless card - or the mouse controller - has that interrupt pending even before the driver gets to initialize, and depending on just which one loads first, it will be unhappy - because it will see an interrupt that it isn't able to handle, and that thus just isn't going away.. Does the box still work? It may well be that once all drivers have had a chance to initialize their hardware properly, the problem is just gone, and that the interim reports about not being able to handle the irq are just temporary noise. Of course, even if it works, the noise _is_ actually indicative of a problem. There shouldn't be any pending interrupts, especially not level-triggered ones. And it can cause a non-working mouse if you don't load the driver for the wireless card (or vice versa). What was the previous kernel you ran on that machine, just out of interest? If it hasn't happened before, it would be interesting to know when it started happening... Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2005 07:27 PM, Sean wrote: > On Thu, February 17, 2005 4:27 am, Roland Kuhn said: > > >>The difference comes after the merge. Suppose Andrew didn't push >>everything to Linus. Then new patches come in, both trees change. In >>this situation it is very time consuming with subversion to work out >>the changes which still have to go from Andrew's tree to Linus' tree. > > > Since Andrew does this all by hand now, subversion / arch / whatever could > only improve the situation. And the kicker is that using a free system > would mean the result could be dumped into BK for those that want to use > it. The reverse unfortunately isn't true; not because of technical > reasons, but because of license restrictions. well I think Andrew will have tonsof small helper scripts for that. I doubt he has time to try out various vcs ... (especially if they are so complicated to use like arch). - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCFTecjBz/yQjBxz8RAqx5AJ9TCxTpvXkfnUbGiPM67VQsa5RVlwCeMXPR 9RPlx/090x7ALlctuvSnWo4= =9Xst -END PGP SIGNATURE- - 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: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2005 01:57 PM, Theodore Ts'o wrote: > Compare the number of developers, the number of overlapping > simultaneous development trees, and the number of patches that touch > overlapping files, and you'll begin to start to appreciate the > difference between a system that can work for Linux, and a system that > can working for simpler projects. apache might be simpler, but I doubt that for gcc. But well lets see what the gcc guys will decide. - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCFTb7jBz/yQjBxz8RAqK+AJ9qyQaqg/zQz/xt6XKpLjlJIC5u9gCbBrPg D/3yjB5iv7HCSMtVOIZx6Xo= =Zfsd -END PGP SIGNATURE- - 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: UDP and e1000 : Simple test, little bugs.
Vincent Roqueta wrote: Hello all, I am working on NFS interoperabiity and I experiment some problems with UDP. The problem appear between the linux 2.6.10rc1 and 2.6.10rc2, and is still present in the last kernel (2.6.11rc3) With NFSv3: Client send a 32k file splited into 22 IP fragments. The problem is the server only receive 17 fragments. More investigation tell me that the server reveive 17 fragments because the client only send 17 IP fragments. As the NFS client code is exactly the same between the 2.6.10rc1 and 2.6.10rc2 I tried to write a simple UDP client server, to be sure there is no relation between this bug and NFS. Client create a buffer of X bytes and fill it with the 'A' symbol. Then it write it over a udp socket (sendto). Server read the first 1024KB sent. If X is <26000 the write is done with sucess. Else it fail. (Typicaly for a 32KB size, as for NFS) Try setting the socket send buffer size larger. By default it's quite small, and so it may not accept a large UDP frame. Ben -- 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/
cdrecord stuck in D state with USB DVD burner
I have a system with two USB DVD burners. If I burn a disc on both at the
same time, one of the dvdrecord processes hangs (unkillably stuck in the
D state). The usb-storage kernel thread was also stuck in the D state.
I power-cycled both burners. The disconnect appeared in the logs but
they were not detected when I powered them back on. After this, khubd
and scsi_eh_12 kernel threads were stuck in the D state.
This is with kernel 2.6.11-rc4. Fedora's 2.6.10-1.766_FC3smp also has the
same problem.
This is repeatable. I have no trouble if I only write to one drive at a time.
The drives are:
kernel: USB Mass Storage support registered.
kernel: Vendor: _NEC Model: DVD_RW ND-3520A Rev: 1.04
kernel: Type: CD-ROM ANSI SCSI revision: 00
kernel: sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
kernel: Uniform CD-ROM driver Revision: 3.20
kernel: Vendor: PLEXTOR Model: DVDR PX-716ARev: 1.04
kernel: Type: CD-ROM ANSI SCSI revision: 00
kernel: sr1: scsi3-mmc drive: 94x/94x writer cd/rw xa/form2 cdda tray
Here is sysrq-t output for the stuck processes:
cdrecord D 5704 5885 5884 5892 (NOTLB)
f1eb3c20 0082 c0101f64 c0350ff7 f700be00 f887e083 f89f4943
e921f380 e921f380 e921f380 232c9ac0 000f4281 f7a6b080 232c9ac0
000f4281 f43e9758 f1eb3d18 f1eb3d1c f1eb3c8c c03516d7
Call Trace:
[] __up+0x1c/0x20
[] __up_wakeup+0x7/0x10
[] scsi_done+0x0/0x16 [scsi_mod]
[] .text.lock.scsiglue+0xb/0x48 [usb_storage]
[] wait_for_completion+0xce/0x2da
[] scsi_request_fn+0x392/0x862 [scsi_mod]
[] default_wake_function+0x0/0xc
[] default_wake_function+0x0/0xc
[] blk_execute_rq+0x10d/0x12e
[] follow_page+0xd/0x11
[] get_user_pages+0x156/0x63c
[] __generic_unplug_device+0x16/0x31
[] sg_io+0x189/0x2b6
[] scsi_cmd_ioctl+0x2bb/0x426
[] avc_has_perm_noaudit+0x56/0xf4
[] selinux_file_ioctl+0xdc/0x310
[] ehci_work+0x2b/0x94 [ehci_hcd]
[] cdrom_ioctl+0x2f/0xc9e
[] default_wake_function+0x0/0xc
[] sr_block_ioctl+0x52/0x59 [sr_mod]
[] blkdev_ioctl+0x123/0x393
[] block_ioctl+0x0/0xd
[] do_ioctl+0x39/0x52
[] vfs_ioctl+0x57/0x195
[] sys_ioctl+0x5f/0x6f
[] sysenter_past_esp+0x52/0x75
cdrecord D F7B10D90 4932 5892 5885 (NOTLB)
e91a5c20 0082 f7b10d90 f7b10d90 e921f680 f76c6600 f7c1aa24 f8a1f455
f76f8db4 0046 c042f9c0 a0f09280 000f42be f7cee620 a0f09280
000f42be f3f4f468 e91a5d18 e91a5d1c e91a5c8c c03516d7 f7c1aa24
Call Trace:
[] sr_init_command+0x244/0x3f0 [sr_mod]
[] wait_for_completion+0xce/0x2da
[] scsi_request_fn+0x392/0x862 [scsi_mod]
[] default_wake_function+0x0/0xc
[] default_wake_function+0x0/0xc
[] blk_execute_rq+0x10d/0x12e
[] as_set_request+0x14/0x63
[] as_set_request+0x0/0x63
[] elv_set_request+0x20/0x23
[] get_request+0x2d5/0x592
[] __generic_unplug_device+0x16/0x31
[] generic_unplug_device+0x75/0x151
[] elv_next_request+0x2d/0xf0
[] sg_io+0x189/0x2b6
[] scsi_cmd_ioctl+0x2bb/0x426
[] avc_has_perm_noaudit+0x56/0xf4
[] selinux_file_ioctl+0xdc/0x310
[] ehci_work+0x2b/0x94 [ehci_hcd]
[] cdrom_ioctl+0x2f/0xc9e
[] do_page_fault+0x1c4/0x54b
[] sr_block_ioctl+0x52/0x59 [sr_mod]
[] blkdev_ioctl+0x123/0x393
[] block_ioctl+0x0/0xd
[] do_ioctl+0x39/0x52
[] vfs_ioctl+0x57/0x195
[] sys_ioctl+0x5f/0x6f
[] sysenter_past_esp+0x52/0x75
scsi_eh_12D 7608 2276 1 2277 1771 (L-TLB)
f7647e54 0046
f7668b08 f77d3280 0092 b41a6ac0
000f42af f772ecf8 f700bf70 f700be00 f700bf74 f7647ec0 c03516d7 f7668a00
Call Trace:
[] wait_for_completion+0xce/0x2da
[] unlink1+0x16/0x26
[] hcd_unlink_urb+0x3b6/0x4f6
[] default_wake_function+0x0/0xc
[] default_wake_function+0x0/0xc
[] command_abort+0x8b/0x19f [usb_storage]
[] schedule+0x2d2/0x609
[] scsi_try_to_abort_cmd+0xbd/0x1bd [scsi_mod]
[] scsi_eh_abort_cmds+0x45/0xde [scsi_mod]
[] __wake_up_locked+0x1f/0x21
[] scsi_unjam_host+0x127/0x2ce [scsi_mod]
[] default_wake_function+0x0/0xc
[] scsi_error_handler+0x14e/0x205 [scsi_mod]
[] scsi_error_handler+0x0/0x205 [scsi_mod]
[] kernel_thread_helper+0x5/0xb
usb-storage D 0D80 6536 2277 1 2528 2276 (L-TLB)
f77f1dd8 0046 f7b91c14 0d80 0080 376cd08d 5c80 f77f1dc8
f700ce00 f700ce00 0010 f77f1dc8 f7668b08 f89e558f 23882840
000f4281 f7a6b1e8 f77f1eac f77f1eb0 f77f1e44 c03516d7 c02b8394
Call Trace:
[] ehci_urb_enqueue+0x5b/0xb8 [ehci_hcd]
[] wait_for_completion+0xce/0x2da
[] hcd_submit_urb+0x1aa/0x2df
[] ehci_urb_enqueue+0x5b/0xb8 [ehci_hcd]
[] default_wake_function+0x0/0xc
[] usb_submit_urb+0x1c2/0x2b2
[] default_wake_function+0x0/0xc
[] usb_stor_msg_common+0x1a4/0x1e8 [usb_storage]
[] urb_destroy+0x0/0x5
[] kref_put+0x28/0x63
[] sg_clean+0x84/0x91
[RFC][PATCH] Memory Hotplug
The attached patch is a prototype implementation of memory hot-add. It
allows you to boot your system, and add memory to it later. Why would
you want to do this? Well, it's a step before memory removal which can
help cope with things like bad RAM. This is primarily useful for a
machine that you don't want to reboot during an upgrade.
For instance, on my 1GB laptop, I booted with mem=512M on the kernel
command-line. Once I had booted, I did the following:
cd /sys/devices/system/memory
echo 0x2000 > probe
echo 0x3000 > probe
echo online > memory2/state
echo online > memory3/state
and the last 512MB of my laptop's memory was onlined. The onlining
operations can occur from an /etc/hotplug script if desired.
Here's the config file that I used:
http://www.sr71.net/patches/2.6.11/2.6.11-rc3-mhp1/configs/config-i386-T41-laptop
The important config options are:
CONFIG_MEMORY_HOTPLUG=y
CONFIG_SPARSEMEM=y
CONFIG_SIMULATED_MEM_HOTPLUG=y
This patch depends on the previously posed "Sparse Memory Handling
(hot-add foundation)" patch.
There are a number of individual patches (with descriptions) which are
rolled up in the attached patch: all of the files listed after
"G2-no-memory-at-high_memory-ppc64.patch" from this directory:
http://www.sr71.net/patches/2.6.11/2.6.11-rc3-mhp1/broken-out/
I can post individual patches if anyone would like to comment on them.
-- Dave
--- memhotplug/arch/i386/kernel/setup.c~Y2-page_is_ram_hotplug 2005-02-17 15:51:10.0 -0800
+++ /arch/i386/kernel/setup.c 2005-02-17 15:51:10.0 -0800
@@ -118,6 +118,7 @@
struct edid_info edid_info;
struct ist_info ist_info;
struct e820map e820;
+struct e820map bios_e820;
unsigned char aux_device_present;
@@ -1417,6 +1418,7 @@
else {
printk(KERN_INFO "BIOS-provided physical RAM map:\n");
print_memory_map(machine_specific_memory_setup());
+ bios_e820 = e820;
}
copy_edd();
--- memhotplug/arch/i386/mm/init.c~L1-sysfs-memory-class 2005-02-17 15:51:08.0 -0800
+++ /arch/i386/mm/init.c 2005-02-17 15:51:10.0 -0800
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -191,38 +192,42 @@
extern int is_available_memory(efi_memory_desc_t *);
-int page_is_ram(unsigned long pagenr)
+static int page_is_ram_efi(unsigned long pagenr)
{
+#ifdef CONFIG_EFI
int i;
unsigned long addr, end;
+ efi_memory_desc_t *md;
- if (efi_enabled) {
- efi_memory_desc_t *md;
-
- for (i = 0; i < memmap.nr_map; i++) {
- md = &memmap.map[i];
- if (!is_available_memory(md))
-continue;
- addr = (md->phys_addr+PAGE_SIZE-1) >> PAGE_SHIFT;
- end = (md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT)) >> PAGE_SHIFT;
-
- if ((pagenr >= addr) && (pagenr < end))
-return 1;
- }
- return 0;
+ for (i = 0; i < memmap.nr_map; i++) {
+ md = &memmap.map[i];
+ if (!is_available_memory(md))
+ continue;
+ addr = (md->phys_addr+PAGE_SIZE-1) >> PAGE_SHIFT;
+ end = (md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT)) >> PAGE_SHIFT;
+ if ((pagenr >= addr) && (pagenr < end))
+ return 1;
}
+#endif /* CONFIG_EFI */
+ return 0;
+}
- for (i = 0; i < e820.nr_map; i++) {
+int page_is_ram_e820(unsigned long pagenr, struct e820map *local_e820)
+{
+ int i;
+ unsigned long addr, end;
+
+ for (i = 0; i < local_e820->nr_map; i++) {
- if (e820.map[i].type != E820_RAM) /* not usable memory */
+ if (local_e820->map[i].type != E820_RAM) /* not usable memory */
continue;
/*
* !!!FIXME!!! Some BIOSen report areas as RAM that
* are not. Notably the 640->1Mb area. We need a sanity
* check here.
*/
- addr = (e820.map[i].addr+PAGE_SIZE-1) >> PAGE_SHIFT;
- end = (e820.map[i].addr+e820.map[i].size) >> PAGE_SHIFT;
+ addr = (local_e820->map[i].addr+PAGE_SIZE-1) >> PAGE_SHIFT;
+ end = (local_e820->map[i].addr+local_e820->map[i].size) >> PAGE_SHIFT;
if ((pagenr >= addr) && (pagenr < end))
return 1;
}
@@ -543,6 +548,7 @@
int tmp;
int bad_ppro;
+
#ifdef CONFIG_FLATMEM
if (!mem_map)
BUG();
@@ -617,6 +623,104 @@
#endif
}
+int add_one_highpage(struct page *page, int pfn, int bad_ppro)
+{
+ /*
+ * there's no page_is_ram() check because that only covers ram
+ * from boot-time. We learned about this ram later
+ */
+ if ( !(bad_ppro && page_kills_ppro(pfn))) {
+ set_bit(PG_highmem, &page->flags);
+ set_page_count(page, 1);
+ __free_page(page);
+ totalhigh_pages++;
+ } else {
+ SetPageReserved(page);
+ BUG(); /* for debugging. remove later */
+ }
+ totalram_pages++;
+#ifdef CONFIG_FLATMEM
+ max_mapnr++;
+#endif
+ num_physpages++;
+ return 0;
+}
+
+
+/*
+ * Not currently handling the NUMA case.
+ * Assuming single node and all memory that
+ * has been added dynamically that would be
+ * onlined here is in HIGHMEM
+ */
+
+void online_page(struct page *page)
+{
+ ClearPageReserved(page);
+ add_one_highpage(page, page_to_pfn(page), 0);
+}
+
+/*
+ * this is for the non-NUMA, single node SMP system case.
+ * Specifically, in the case of x86, we
Re: [ACPI] Call for help: list of machines with working S3 (fwd)
Pavel Machek schrieb: > >>>I'm not sure if you can push the whole industry at once. >> >>The goal is to know what to tell the system vendors >>interested in supporting Linux what they should do >>with their BIOS on future platforms. >> >>I believe our message should be: >>1. BIOS should save/restore video in S3 > > Actually, that'd expect too much of BIOS writers. I believe right > solution is "POST video as you do during normal boot in S3 resume". Why not leave the choice to the BIOS writers? If some are able to save/restore video state by themselves, we shoudln't stop them. As long as the state after resume accepts setting the mode without lockup, we should be fine. >>2. Use Intel's ACPICA ASL compiler -- if not for production, >>then at least as a static source code checker for validation. > > > 3. Try to boot linux (here's live cd). If it complains about bios bugs > (dmesg | grep ...), try to see if it is not indeed your bug. That could even be automated more. A live cd which boots, performs a few tests, displays the results on screen and offers an option to save these results to usbstick/network/disk/whatever. After saving the boot results, it will perform a S3 suspend and resume and display/save the results of that, too. If Intel have enough money, they could provide the functionality on a hard disk and it would have the benefit that S4 could be tested as well. If the disk has a FAT32 partition, the results can be saved there. Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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: [BK] upgrade will be needed
On Thu, February 17, 2005 6:54 pm, Lee Revell said: > Ed did not say it was a choice between BK and nothing. He said "Linus > has tried other SCMs. They did not suffice." Did you even read his > comment? The point you missed is that it's not an honest comparison to look at the post BK/ pre BK situation and pretend that BK was the only option that would have produced the list of benefits that Ed outlined. Linus has been known to be wrong before. > Please don't cc: me on this thread anymore, unless it's about some work > you did to bring BK functionality to a free SCM. No need to respond. Cheers, Sean - 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/2] page table iterators
On Thu, Feb 17, 2005 at 03:30:31PM -0800, David S. Miller wrote: > On Fri, 18 Feb 2005 00:03:42 +0100 > Andi Kleen <[EMAIL PROTECTED]> wrote: > > > And to be honest we only have about 6 or 7 of these walkers > > in the whole kernel. And 90% of them are in memory.c > > While doing 4level I think I changed all of them around several > > times and it wasn't that big an issue. So it's not that we > > have a big pressing problem here... > > It's super error prone. A regression added by your edit of these Actually it was in Nick's code (PUD layer ;-). But I won't argue that my code didn't have bugs too... > walkers for the 4level changes was only discovered and fixed > yesterday by the ppc folks. > > I absolutely support any change which consolidates these things. The problem is just that these walker macros when they do all the lazy walking stuff will be quite complicated. And I don't really want another uaccess.h-like macro mess. Yes currently they look simple, but that will change. Open coding is probably the smaller evil. And they're really not changed that often. -Andi - 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 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
[Sorry for the late answer.] On Tue, Feb 15, 2005 at 09:44:41PM -0600, Ray Bryant wrote: > > > > > >Sorry, but the only real difference between your API and mbind is that > >yours has a pid argument. > > > > That may be true, but the internals of the implementations have got > to be pretty different as near as I can tell. So just beause the Not necessarily. E.g. Steve's file attribute patch actually implemented very simple page migration into NUMA API because he needed it to solve some problems with allocation. It was even exposed as a new mbind() flag. > >Main cases: > > > >- Program is NUMA API aware. Fine. It takes care of its own. > > Yes, we could migrate this program using a migration facility > embedded in the NUMA API. > > >- Program is not aware, but is started with a process policy from > >numactl/cpusets/batch scheduler. Already covered too in NUMA API. > > Hmmm What about the case where no NUMA API is used and cpusets First the NUMA API internally doesn't care that much about this case. It just considers no policy as "DEFAULT" policy which just happens to be what you call first-touch. But there is no fundamental reason you can't change the policy of an existing program externally. It is already implemented for some kinds of named objects (shmfs etc.), but it can be extended to more. > >- Program is not aware and hasn't been started with a policy > >(or has and you change your mind) but you want to change it later. > I'm having a little trouble parsing the "it" in that sentence. > Does that sentence mean "you want to change the NUMA API later"? The policy. In this case policy means including the page placement (this would be MPOL_F_STRICT) > What if there never is a NUMA API structure associated with > the program other than the default (local) policy? If you have some generic facility to change policy externally it doesn't matter if there was policy before or not. > The fundamental disconnect here is that I think that very few > programs use the NUMA API, and you think that most programs do. All programs use NUMA policy (assuming you have a CONFIG_NUMA kernel) Internally it's all the same. Hmm, I see perhaps my distinction of these cases with programs already using NUMA API and not using it was not very useful and lead you to a tangent. Perhaps we can just drop it. I think one problem that you have that you essentially want to keep DEFAULT policy, but change the nodes. NUMA API currently doesn't offer a way to do that, not even with Steve's patch that does simple page migration. You only get a migration when you set a BIND or PREFERED policy, and then it would stay. But I guess you could force that and then set back DEFAULT. It's a big ugly, but not too bad. > > Let me expand on that a bit. What most programs do on Altix is > to do first-touch to get data allocated locally. That is, lets > say you have a big array that your parallel computation is going to > work on. The programmer would sit down and say, I want processor 1 > to work on this part of the array, processor 2 on that part, etc. > Then the programmer writes code that causes each processor to touch > the portions of the data array that should be allocated locally on > that processor. Bingo, storage is now allocated the way the user > wants it, and no NUMA API call was ever issued. Sure, but NUMA API goes to great pains to handle such programs. > > Yes, it is clumsy, but that is because these programs were written > before your NUMA API came into being. Now we simply can't go back > to these people (many of them ISV's) and say "Please rewrite your > code to use the NUMA API." So we are left with a pile of legacy > programs that we have to be able to migrate that don't have any > NUMA api data structures associated with them. What are we > supposed to do in this case? > > We can't necessarily construct a NUMA API that will cause storage > to be allocated as the programmer intended, because we can't fathom > what the programmer was trying to accomplish based on the state > of the program when we go to migrate it. So how would we use > a migration facility embedded into the NUMA API to migrate this > program and maintain its old topology? numactl went to great pains to handle such programs. Take a look at all the command line options ;-) If the program is using shm and you applied the patch to do page migration in mbind() you could handle it right now: - map the shm segment into the management process. - change policy with mbind(), triggering page migration - set back default policy. For other objects (files etc.) there are patches in the pipeline. The only hole that's still there is anonymous memory, but I think we can fill that much simpler than what you're proposing, with a "migrate whole process except when policy says otherwise" call. > >That's the new case we discuss here. > > > >Now how to change policy of objects in an already running process. > > > > If the running process
Re: [BK] upgrade will be needed
On Thu, 2005-02-17 at 18:32 -0500, Sean wrote: > On Thu, February 17, 2005 6:25 pm, Ed Tomlinson said: > > Linus has tried other SCMs. They did not suffice. I remember the preBK > > days, when you had to post a patch half a dozen time to get it merged. > > Patches were being missed left right and center. This changed after BK. > > We _are_ getting large benefits from BK. They may be hard to see at our > > side of the keyboard - but I believe Linus when he says BK is the best > > tool for him. That this probably will not be the case for ever. Think > > it still is for now though. > > It's not a choice between BK or nothing. Much of the improvements you're > attributing to BK would have been realized with any other SCM system too. > Ed did not say it was a choice between BK and nothing. He said "Linus has tried other SCMs. They did not suffice." Did you even read his comment? Please don't cc: me on this thread anymore, unless it's about some work you did to bring BK functionality to a free SCM. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci/quirks.c: unhide SMBus device on Samsung P35 laptop
On Thu, Feb 17, 2005 at 03:49:17AM +0100, Carl-Daniel Hailfinger wrote: > Hi, > > this patch is needed to make the SMBus device on my Samsung P35 > laptop visible. By default, it doesn't appear as a pci device. > > Patch tested, works perfectly for me. Please apply. Applied, 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/
Re: avoiding pci_disable_device()...
On Mon, Feb 14, 2005 at 02:46:38PM -0800, Roland Dreier wrote: > OK, I'm happy to go along with that (it definitely simplifies my > driver code). Here's the patch. > > > Remove the call to request_mem_region() in msix_capability_init() to > grab the MSI-X vector table. Drivers should be using > pci_request_regions() so that they own all of the PCI BARs, and the > MSI-X core should trust it's being called by a correct driver. > > Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> Applied, 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/
Re: [PATCH] quiet non-x86 option ROM warnings
On Thu, 17 Feb 2005, Jon Smirl wrote: > On Fri, 18 Feb 2005 09:47:15 +1100, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> wrote: > > We could provide additional helpers, like pci_find_rom_partition(), > > which takes the architecture code as an argument. It would check the > > signature, and iterate all "partitions" til it finds the proper > > architecture (or none). > > The spec allows for it but has anyone actually seen a ROM with > multiple images in it? I haven't but I only work on x86. > Yes. Many SCSI and fibre-channel cards carry multiple images. -- Andrew Vasquez - 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: Fix u32 vs. pm_message_t in USB [was Re: PATCH: Address lots of pending pm_message_t changes]
On Tue, Feb 15, 2005 at 01:39:35AM +0100, Pavel Machek wrote: > Hi! > > This fixes (part of) u32 vs. pm_message_t confusion in USB. It should > cause no code changes. Please apply, Large portions of this patch are already in my tree (and hence the -mm tree.) Care to rediff against the latest -mm and resend the patch? 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/
Re: [PATCH 2/2] page table iterators
On Fri, Feb 18, 2005 at 10:21:03AM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2005-02-18 at 00:03 +0100, Andi Kleen wrote: > > > And to be honest we only have about 6 or 7 of these walkers > > in the whole kernel. And 90% of them are in memory.c > > While doing 4level I think I changed all of them around several > > times and it wasn't that big an issue. So it's not that we > > have a big pressing problem here... > > We have about 50% of them in memory.c :) But my main problem is more > that every single of them is implemented slightly differently. No much more. But I only count real walkers, not stuff like vmalloc. The ioremap duplication over architectures is a bit annoying, but the fix for that would be to factor the code out completely, not only improve walking. -Andi - 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] add umask parameter to procfs
Rene Scharfe <[EMAIL PROTECTED]> wrote: > > Add proc.umask kernel parameter. It can be used to restrict permissions > on the numerical directories in the root of a proc filesystem, i.e. the > directories containing process specific information. > > E.g. add proc.umask=077 to your kernel command line and all users except > root can only see their own process details (like command line > parameters) with ps or top. It can be useful to add a bit of privacy to > multi-user servers. > > The patch has been inspired by a similar feature in GrSecurity. > > It could have also been implemented as a mount option to procfs, but at > a higher cost and no apparent benefit -- changes to this umask are not > supposed to happen very often. Actually, the previous incarnation of > this patch was implemented as a half-assed mount option, but I didn't > know then how easy it is to add a kernel parameter. The feature seems fairly obscure, although very simple. Is anyone actually likely to use this? > > +static umode_t umask = 0; a) I think the above should be called proc_umask. b) You shouldn't initialise it. c) When adding a kernel parameter you should update Documentation/kernel-parameters.txt - 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: [BK] upgrade will be needed
On Thu, February 17, 2005 6:25 pm, Ed Tomlinson said: >> Yes, I do remember that post. But i'm not arguing from an ideological >> basis; i'm arguing on practical grounds that the price of using BK is >> too >> high for its supposed benefits. I've not seen anyone else make that > > Huh? This ideology in my books. No. It's about recognizing the needs of more people than just the few at the top. Besides, with a free tool at the Head, bk could continue to be used underneath by Linus and anyone else. And others in the community could use their preferred tools too. > Linus has tried other SCMs. They did not suffice. I remember the preBK > days, when you had to post a patch half a dozen time to get it merged. > Patches were being missed left right and center. This changed after BK. > We _are_ getting large benefits from BK. They may be hard to see at our > side of the keyboard - but I believe Linus when he says BK is the best > tool for him. That this probably will not be the case for ever. Think > it still is for now though. It's not a choice between BK or nothing. Much of the improvements you're attributing to BK would have been realized with any other SCM system too. Cheers, Sean - 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/2] page table iterators
On Fri, 18 Feb 2005 00:03:42 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > And to be honest we only have about 6 or 7 of these walkers > in the whole kernel. And 90% of them are in memory.c > While doing 4level I think I changed all of them around several > times and it wasn't that big an issue. So it's not that we > have a big pressing problem here... It's super error prone. A regression added by your edit of these walkers for the 4level changes was only discovered and fixed yesterday by the ppc folks. I absolutely support any change which consolidates these things. - 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: [ACPI] Call for help: list of machines with working S3 (fwd)
Hi! Sorry, I was too fast with my mail client. Please cc: Len in your replies. To: Len Brown <[EMAIL PROTECTED]> Subject: Re: [ACPI] Call for help: list of machines with working S3 X-Warning: Reading this can be dangerous to your mental health. Hi! > > I'm not sure if you can push the whole industry at once. > > The goal is to know what to tell the system vendors > interested in supporting Linux what they should do > with their BIOS on future platforms. > > I believe our message should be: > 1. BIOS should save/restore video in S3 Actually, that'd expect too much of BIOS writers. I believe right solution is "POST video as you do during normal boot in S3 resume". > 2. Use Intel's ACPICA ASL compiler -- if not for production, > then at least as a static source code checker for validation. 3. Try to boot linux (here's live cd). If it complains about bios bugs (dmesg | grep ...), try to see if it is not indeed your bug. -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - End forwarded message - -- 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: [BK] upgrade will be needed
On Thursday 17 February 2005 11:58, Sean wrote: > On Thu, February 17, 2005 11:55 am, Chris Friesen said: > > > If you look at the archives, there have been a *lot* of people saying > > very much the same thing as you. I suspect people are getting tired of > > giving the same responses all the time. > > > > Here is what Linus had to say about it a while back: > > > > If people in the open-source SCM community wake up and notice that > > the current open-source SCM systems aren't cutting it, that's _good_. > > But it's absolutely NOT an excuse to use them today. Sorry. I use > > CVS at work, and I could never use it for Linux. I took a look at > > subversion, and it doesn't even come close to what I wanted. > > > > And I personally refuse to use inferior tools because of ideology. In > > fact, I will go as far as saying that making excuses for bad tools > > due to ideology is _stupid_, and people who do that think with their > > gonads, not their brains. > > Chris, > > Yes, I do remember that post. But i'm not arguing from an ideological > basis; i'm arguing on practical grounds that the price of using BK is too > high for its supposed benefits. I've not seen anyone else make that Huh? This ideology in my books. > argument here on the list and it is something that Linus may not have > given full consideration to. At least the comment that you quote gives > no consideration to it at all. Linus has tried other SCMs. They did not suffice. I remember the preBK days, when you had to post a patch half a dozen time to get it merged. Patches were being missed left right and center. This changed after BK. We _are_ getting large benefits from BK. They may be hard to see at our side of the keyboard - but I believe Linus when he says BK is the best tool for him. That this probably will not be the case for ever. Think it still is for now though. 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: PCI access mode on x86_64
On Mon, Feb 14, 2005 at 01:02:05PM +0100, Andi Kleen wrote: > On Mon, Feb 14, 2005 at 10:47:01AM +0100, Piotr Kaczuba wrote: > > On Mon, Feb 14, 2005 at 10:18:43AM +0100, Andi Kleen wrote: > > > Piotr Kaczuba <[EMAIL PROTECTED]> writes: > > > > Is there a reason why "PCI access mode" config option isn't available > > > > for > > > > x86_64? Due to this, PCIE config options aren't available either. > > > > > > There is no 64bit PCI BIOS, so access is always direct. > > > > > > I assume you mean mmconfig access with "PCIE config options", that is > > > a separate config option and available. > > > > I mean the PCIEPORTBUS option which depends on PCI_GOMMCONFIG or > > PCI_GOANY. I assume that due to PCI_MMCONFIG / PCI_GOMMCONFIG mismatch > > it's not available on x86_64. > > Ok, that's a bug in PCIEPORTBUS. Best is probably to > completely remove the dependency, it doesn't make much sense > (the code has to handle the case of mmconfig not being available at > runtime anyways) > > -Andi > > Remove bogus dependency in PCI Express root driver. Applied, 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/
Re: [PATCH 2/2] page table iterators
On Fri, 2005-02-18 at 00:03 +0100, Andi Kleen wrote: > And to be honest we only have about 6 or 7 of these walkers > in the whole kernel. And 90% of them are in memory.c > While doing 4level I think I changed all of them around several > times and it wasn't that big an issue. So it's not that we > have a big pressing problem here... We have about 50% of them in memory.c :) But my main problem is more that every single of them is implemented slightly differently. Going Nick's way is a good start. If they are all consolidated to use the same macro, they will be easier for you to change later on anyway. 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 2.6] Add PCI quirk for SMBus on the Toshiba Satellite A40
On Sun, Feb 13, 2005 at 08:46:39PM +0100, Jean Delvare wrote: > Hi all, > > The Toshiba Satellite A40 laptop hides its SMBus device, much like a > number of Asus boards reputedly do. This prevents access to the LM90 > hardware monitoring chip. This simple patch extends the PCI quirk used > for the Asus and HP systems to this Toshiba laptop. > > Please consider for merge into the PCI subsystem, > thanks. > > Signed-off-by: Frans Pop <[EMAIL PROTECTED]> > Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> Applied, 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/
Re: [ACPI] Call for help: list of machines with working S3
Hello Pavel! On Mon 14 Feb 2005 22:11, Pavel Machek wrote: > Stefan provided me initial list of machines where S3 works (including > video). If you have machine that is not on the list, please send me a > diff. If you have eMachines... I'd like you to try playing with Sorry, but a diff of what? Of the list? > Table of known working systems: > > Model hack (or "how to do it") > -- IBM ThinkPad T42p (2373-GTG [1]) acpi_sleep=s3_bios (2) More info available upon request, but in general: - Debian unstable - vanilla kernel 2.6.10 - ACPI patch 20050125 - BlueZ patch -mh4 - IBM trackpoint patch [2] - radeonfb - radeon XFree86 4.3.0.dfsg.1-11 - all modules my laptop support installed (and loaded ;-) ) - I used a script that switch to vc1 and stop mysql (this is a known problem [3] [4]), then "echo -n [mem|disk] > /sys/power/state" I've a working S4 with the same configuration, too. But it seems I still suffer a problem about hwclock I already reported with another laptop [5] [6]. In this case, the command proposed seems not working anymore (I should test more deeply, just a question of time ;-) ). Anyway, this laptop works very well! I've also a docking station [7], I'll test with it ASAP. Thx, bye, Gismo / Luca [1] http://www5.pc.ibm.com/ch/products.nsf/$wwwPartNumLookup/_UC2GTSE?OpenDocument [2] http://people.clarkson.edu/~evanchsa/ [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259745 [4] http://bugs.mysql.com/bug.php?id=4596 [5] http://sourceforge.net/mailarchive/message.php?msg_id=9844751 [6] http://sourceforge.net/mailarchive/message.php?msg_id=9864402 [7] http://www5.pc.ibm.com/ch/products.nsf/$wwwPartNumLookup/_74P6733?OpenDocument pgpkSj2De7ysa.pgp Description: PGP signature
Re: [ACPI] Call for help: list of machines with working S3
On Thu, 2005-02-17 at 05:15, Vojtech Pavlik wrote: > I'm not sure if you can push the whole industry at once. The goal is to know what to tell the system vendors interested in supporting Linux what they should do with their BIOS on future platforms. I believe our message should be: 1. BIOS should save/restore video in S3 2. Use Intel's ACPICA ASL compiler -- if not for production, then at least as a static source code checker for validation. thanks, -Len - 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: Please open sysfs symbols to proprietary modules
On Thu, 03 Feb 2005 09:41:00 +0100, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > On Wed, 2005-02-02 at 17:56 -0500, Pavel Roskin wrote: > > Hello! > > > > I'm writing a module under a proprietary license. I decided to use sysfs > > to do the configuration. Unfortunately, all sysfs exports are available > > to GPL modules only because they are exported by EXPORT_SYMBOL_GPL. > > I suggest you talk to a lawyer and review the general comments about > binary modules with him (http://people.redhat.com/arjanv/COPYING.modules > for example). You are writing an addition to linux from scratch, and it > is generally not considered OK to do that in binary form (I certainly do > not consider it OK). So what about companies like ImageStream who write proprietary Linux network drivers for their hardware from scratch with no previous ports from another OS? - 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: [Problem] slow write to dvd-ram since 2.6.7-bk8
On Wed, Feb 16, 2005 at 23:29:24 +0100, Droebbel wrote:
> On Mi, 2005-02-16 at 22:55 +0100, Droebbel wrote:
> >Some new information:
> >
> >2.6.7 is ok, 2.6.7-mm2 is not ok, 2.6.7 with just the linus-patch from
> >mm2 is ok, 2.6.7 with linus.patch from mm3 isn't.
> >So I took some of the patches from the broken-out mm2 and tested them
> >seperately.
> >
> >The vmscan-dont-reclaim-too-many-pages.patch led to the said reduction
> >of writing speed. I reverse-applied it to 2.6.8.1, where it seems to
> >solve the problem.
>
> Sorry, have to correct that: it seemed to help at my tests with dd
> (write 1G of zeroes to a file). Copying a file with mc still shows
> around 1.4MB/s. Could be worse, but is definitely not ok. It *is* better
> with 2.6.7.
Here are some numbers with my setup. I always wrote 1 GB of data to the
same DVD-RAM disc (EMTEC), to the device directly and to a fresh ext2
on
the disc.
kernel 2.6.10:
$ time { sudo dd if=/dev/zero of=bigfile bs=64k count=16000 ; sync ; }
real32m5.025s
$ time {sudo dd if=/dev/zero of=/dev/cdrom bs=64k count=16000 ; sync ;}
real29m41.980s
kernel 2.6.7:
$ time { sudo dd if=/dev/zero of=bigfile bs=64k count=16000 ; sync ; }
real13m23.688s
$ time {sudo dd if=/dev/zero of=/dev/cdrom bs=64k count=16000 ; sync ;}
real13m14.609s
Regards,
Tino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: possible leak in kernel 2.6.10-ac12
Parag Warudkar wrote: On Wednesday 16 February 2005 06:28 pm, Pedro Venda wrote: Having upgraded most of them to 2.6.10-ac12, one of them showed a linear growth of used memory over the last 7 days, after the first 2.6.10-ac12 boot. It came to a point that it started swapping and the swap usage too started to grow linearly. cat /proc/slabinfo please. I am also seeing similar symptoms (although that is with 2.6.11-rc4 there is a possibility of a common bug) here and I seem to have linearly growing size-64 in slabinfo. There has been discussion in another thread about a leak related to network activity. You might find more information there, subject contains "NOT BIO" if it helps. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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/2] page table iterators
> I though about both ways yesterday, and in the end, I prefer Nick stuff, > at least for now. It gives us also more flexibility to change gory > implementation details in the future. I still have to run it through a > bit of torture testing though. They're really solving different problems. My code is just aimed at getting x86-64 fork/exec/etc. as fast as before 4level again (currently they are significantly slower because they have to walk a lot more page tables) The problem is that the index based approach (I think you have to use indexes for this, pointers get very messy) probably does not fit very well into Nick's complex macros. Nick's macros are essentially just code transformations with some micro optimizations. That's not bad, but it won't give you the big speedups the lazy walking approach will give. And to be honest we only have about 6 or 7 of these walkers in the whole kernel. And 90% of them are in memory.c While doing 4level I think I changed all of them around several times and it wasn't that big an issue. So it's not that we have a big pressing problem here... -Andi - 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] quiet non-x86 option ROM warnings
On Thu, 2005-02-17 at 17:59 -0500, Jon Smirl wrote: > On Fri, 18 Feb 2005 09:47:15 +1100, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> wrote: > > We could provide additional helpers, like pci_find_rom_partition(), > > which takes the architecture code as an argument. It would check the > > signature, and iterate all "partitions" til it finds the proper > > architecture (or none). > > The spec allows for it but has anyone actually seen a ROM with > multiple images in it? I haven't but I only work on x86. Yes, I pretty sure some video cards did that in the past at least, and maybe some scsi cards. It was a while ago, I don't know if this is still true, but it's relatively easy to do, let's just hide all of this logic, along with size & signature checking in a single place, that way, we don't have to duplicate all that logic in drivers... 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] quiet non-x86 option ROM warnings
On Thursday, February 17, 2005 2:59 pm, Jon Smirl wrote: > On Fri, 18 Feb 2005 09:47:15 +1100, Benjamin Herrenschmidt > > <[EMAIL PROTECTED]> wrote: > > We could provide additional helpers, like pci_find_rom_partition(), > > which takes the architecture code as an argument. It would check the > > signature, and iterate all "partitions" til it finds the proper > > architecture (or none). > > The spec allows for it but has anyone actually seen a ROM with > multiple images in it? I haven't but I only work on x86. I haven't seen any either, but maybe the parisc folks have? Jesse - 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: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
Sergio Monteiro Basto wrote: with hdc=scsi haldeamon doesn't recognize cdwriter. but with hdc=ide-scsi (was the original from kernel 2.4) haldaamon reconize my cdwriter ! So this message of this subject just make me wast my time and lose my patience. ( because I forgot to enable haldaemon before to try understand the message ) Still don't understand if I should or not change to ide-cd on my FC3, if not please remove the message, if yes rewrite it please . Since ide-scsi seems needed to do firmware upgrades and multi-session CDs as user, like Mark Twain I believe the reports of death are greatly exaggerated. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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] quiet non-x86 option ROM warnings
On Fri, 18 Feb 2005 09:47:15 +1100, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > We could provide additional helpers, like pci_find_rom_partition(), > which takes the architecture code as an argument. It would check the > signature, and iterate all "partitions" til it finds the proper > architecture (or none). The spec allows for it but has anyone actually seen a ROM with multiple images in it? I haven't but I only work on x86. -- 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: [PATCH] quiet non-x86 option ROM warnings
On Fri, 18 Feb 2005 09:45:50 +1100, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > Can't the size be obtained like any other BAR ? yes, but cards that don't fully decode their ROM address space can waste memory in copy_rom. For example I have a card around here that reports a BAR address space of 128K and has a 2K ROM in it. You only want to copy the 2K, not the 128K. -- 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: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
kernel wrote:
On Tue, 2005-02-15 at 14:48, Kiniger, Karl (GE Healthcare) wrote:
I can confirm that. Creating a correct iso image from a CD is a
major pain w/o ide-scsi. Depending on what one has done before the iso
image is missing some data at the end most of the time.
(paired with lots of kernel error messages)
Testing was done here using Joerg Schilling's sdd:
sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \
bs=
and most of the time it results in bad iso images
Use isoinfo to get the size in 2k sectors, then
dd if=/dev/cdrom bs=2k count={size} of=my_file
to pull the image. As noted elsewhere this doesn't work if the image
isn't iso-9660.
--
-bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
-
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/2] page table iterators
On Thu, 2005-02-17 at 20:43 +0100, Andi Kleen wrote:
> On Fri, Feb 18, 2005 at 01:03:35AM +1100, Nick Piggin wrote:
> > I am pretty surprised myself that I was able to consolidate
> > all "page table range" functions into a single type of iterator
> > (well, there are a couple of variations, but it's not too bad).
>
> I started a similar project - but it uses the existing loops,
> just using {pte,pmd,pud,pgd}_next. The idea is to optimize
> page table walking by keeping some state in the struct page
> of the page table page that says whether an entry is set
> or not. To make this work I switched everything to indexes
> instead of pointers.
>
> Main problem are some nasty include loops.
I though about both ways yesterday, and in the end, I prefer Nick stuff,
at least for now. It gives us also more flexibility to change gory
implementation details in the future. I still have to run it through a
bit of torture testing though.
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: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
[EMAIL PROTECTED] wrote: On Wed, 16 Feb 2005 10:42:21 +0100, "Kiniger, Karl (GE Healthcare)" said: Have you tested the ISO on some *OTHER* hardware? The impression I got was that the cd was *burned* right by ide-cd, but when *read back*, it bollixed things up at the end of the CD. Using ide-scsi is enough to get all the data till the real end of the CD. OK, so the problem is that ide-cd is able to *burn* the CD just fine, but it suffers lossage when ide-cd tries to read it back... Alan - are the sense-byte patches for ide-cd in a shape to push either upstream or to -mm? The last time I looked at this, the issue was that the user software did a large read and the ide-cd didn't properly return a small data block with no error, but rather returned an error with no data. If you get the size of the ISO image, you can read that with any program which doesn't try to read MORE than that. I don't consider this correct behaviour, but at least I know how to get by it for iso-9660 CDs. For other formats which don't allow determination of data set size except by the contents of the data, this works poorly. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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: E-cards for You
Am 2005-02-17 14:03:08, schrieb Chuck Harding: > Why can't the list owners apply spamassassin to the list's *incoming* > mail stream so we don't ever see this stuff? Nearly every one of the > lists hosted on vger.kernel.org get spammed on a regular basis because > there is no spam filtering before the messages get passed to majordomo. Sorry ? I remember, that for some month I have gotten minimum 15 SPAMs per day from this List. Siche two (???) month it is very silent here.. I think, there was an Admin which had changed the SPAM-Filter setings. But one thing: I an subscribed with two E-Mails to this list, the first one is secret and get all the mails from the List... SPAM is very rarely. The second E-Mail is, which I use to post here... and on which I get per day between 300 and 6000 SPAMs. I run my own spamassassin on my FileServer for all incoming Messges and see only 5-20 messages coming through my filters. Same for the 56 Debian mailinglist where I am subscribed. I do not know, what happen if kernel.org and debian.org deactivate the filters... maybe the Internet connection will not sufficiant to distribute the SPAM. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: [PATCH] quiet non-x86 option ROM warnings
On Thu, 2005-02-17 at 12:56 -0500, Jon Smirl wrote: > On Thu, 17 Feb 2005 09:45:30 -0800, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > Ok, how does this one look to you guys? The r128 driver would need similar > > fixes. > > Do any of the radeon ROMs store multiple images in different formats? > Should the radeon driver loop throught the ROM images looking for one > that it can understand, or is there alway only a single image? If ATI > wanted to they could make ROMs with both x86 and OpenFirmware images > on them. While it's possible, I don't think it's actually done for radeon's (but may for other video cards). Anyway as I wrote earlier, what about a helper that deal with all these things ? 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] quiet non-x86 option ROM warnings
On Thu, 2005-02-17 at 09:45 -0800, Jesse Barnes wrote: > On Thursday, February 17, 2005 9:32 am, Jon Smirl wrote: > > On Thu, 17 Feb 2005 09:29:53 -0800, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > > On Thursday, February 17, 2005 8:33 am, Jon Smirl wrote: > > > > > No, pci_map_rom shouldn't test the signature IMHO. While PCI ROMs > > > > > should have the signature to be recognized as containing valid > > > > > firmware images on x86 BIOSes an OF, it's just a convention on these > > > > > platforms, and I would rather let people put whatever they want in > > > > > those ROMs and still let them map it... > > > > > > > > pci_map_rom will return a pointer to any ROM it finds. It the > > > > signature is invalid the size returned will be zero. Is this ok or do > > > > we want it to do something different? > > > > > > Shouldn't it return NULL if the signature is invalid? > > > > But then you couldn't get to your non-standard ROMs > > Ok, how does this one look to you guys? The r128 driver would need similar > fixes. We could provide additional helpers, like pci_find_rom_partition(), which takes the architecture code as an argument. It would check the signature, and iterate all "partitions" til it finds the proper architecture (or none). Sorry, I'm still in the middle of breakfast, so no patch attached :) 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] quiet non-x86 option ROM warnings
On Thu, 2005-02-17 at 11:33 -0500, Jon Smirl wrote: > On Thu, 17 Feb 2005 11:48:14 +1100, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> wrote: > > On Wed, 2005-02-16 at 15:54 -0800, Jesse Barnes wrote: > > > On Tuesday, February 15, 2005 5:03 pm, Benjamin Herrenschmidt wrote: > > > > What about printing "No PCI ROM detected" ? I like having that info when > > > > getting user reports, but I agree that a less worrying message would > > > > be good. > > > > > > Ok, how about this then? It changes the printks in both drivers to > > > KERN_INFO > > > and describes the situation a bit more accurately. > > > > > > Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]> > > > > > > Thanks, > > > Jesse > > > > > > P.S. Jon, I think the pci_map_rom code is buggy--if the option ROM > > > signature > > > is missing or indicates that there's no ROM, the routine still returns a > > > valid pointer making the caller thing it succeeded. If we fix that up we > > > can > > > fix up the callers. > > > > No, pci_map_rom shouldn't test the signature IMHO. While PCI ROMs should > > have the signature to be recognized as containing valid firmware images > > on x86 BIOSes an OF, it's just a convention on these platforms, and I > > would rather let people put whatever they want in those ROMs and still > > let them map it... > > > > pci_map_rom will return a pointer to any ROM it finds. It the > signature is invalid the size returned will be zero. Is this ok or do > we want it to do something different? Can't the size be obtained like any other BAR ? 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][I2C] Marvell mv64xxx i2c driver
On Wed, Feb 09, 2005 at 02:33:59PM -0700, Mark A. Greer wrote: > > I can't find any definitive policy on this. I kind of like the explicit > return, I don't know why. I've had others make the same comment, > though, so I'll remove them since it obviously bothers people. > > Attached is a replacement patch. > > Thanks again, Bartlomiej. > > Mark > -- > Marvell makes a line of host bridge for PPC and MIPS systems. On those > bridges is an i2c controller. This patch adds the driver for that i2c > controller. > > Please apply. > > Depends on patch submitted by Jean Delvare: > http://archives.andrew.net.au/lm-sensors/msg29405.html > > Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> Applied, 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/
Re: [PATCH 2.6] I2C: New chip driver: sis5595 (resubmit)
On Sun, Feb 06, 2005 at 09:26:41PM +0100, Aur?lien Jarno wrote: > Hi Greg, > > Please find below the new version of the patch against kernel > 2.6.11-rc3-mm1 to add the sis5595 driver (sensor part). > > As you suggested, I have changed the PCI part of the driver, taking the > via686a driver as an example. I have also changed the comparison of > jiffies by using time_after. Applied, 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/
Re: GL520SM Sensor Chip driver
On Fri, Feb 11, 2005 at 04:15:25PM +0100, [EMAIL PROTECTED] wrote: > Port of the Genesys Logic 520SM sensor chip driver from linux 2.4 > > Signed-off-by: Maarten Deprez <[EMAIL PROTECTED]> Applied, 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/
Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver
On Fri, Feb 04, 2005 at 05:04:09PM -0700, Mark A. Greer wrote: > Greg KH wrote: > > >Can you resend it with a proper Changelog description in the top of the > >email and the signed-off-by line? thanks, > > > >greg k-h > > > > > > > Certainly. > -- > > This patch adds support for the ST M41T00 I2C RTC chip. > > This rtc chip has no mechanism to freeze it's registers while being > read; however, it will delay updating the external values of the > registers for 250ms after a register is read. To ensure that a sane > time value is read, the driver verifies that the same registers values > were read twice before returning. > > Also, when setting the rtc from an interrupt handler, a tasklet is used > to provide the context required by the i2c core code. > > Please apply. Applied, 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/
Re: E-cards for You
On Thu, Feb 17, 2005 at 02:03:08PM -0800, Chuck Harding wrote: > Why can't the list owners apply spamassassin to the list's *incoming* > mail stream so we don't ever see this stuff? Nearly every one of the > lists hosted on vger.kernel.org get spammed on a regular basis because > there is no spam filtering before the messages get passed to majordomo. Perhaps because way too big a share of diffs do get blocked by people's SAs out there... CHICKENPOX indeed... Trust me to prefer erring on too liberal instead of blocking too much. > -- > Charles D. (Chuck) Harding <[EMAIL PROTECTED]> Voice: 925-423-8879 /Matti Aarnio - one of <[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: E-cards for You
On Thu, 2005-02-17 at 14:03 -0800, Chuck Harding wrote: > Why can't the list owners apply spamassassin to the list's *incoming* > mail stream so we don't ever see this stuff? Nearly every one of the > lists hosted on vger.kernel.org get spammed on a regular basis because > there is no spam filtering before the messages get passed to majordomo. > Do you actually think there is no spam filtering on the vger lists? Do you have any idea what this list would look like if there were really no spam filtering? Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: E-cards for You
On Thu, 17 Feb 2005 13:20:48 -0800 James Colannino <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > >Greetings! > > > > has sent you an E-Card -- a virtual postcard from > >TheArtHaven.com. You can pickup your card at the TheArtHaven.com website. > > > > > > This is the first time I've ever seen someone send an e-card to a > mailing list... > > James yeah.. :) > - > 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/ Marco Iannantuoni Gentoo Linux 2.6.10-gentoo-r6 +*+ V ( ) ( ' ) ^^ ^^ - 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: E-cards for You
On Thu, 2005-02-17 at 14:03 -0800, Chuck Harding wrote: > Why can't the list owners apply spamassassin to the list's *incoming* > mail stream so we don't ever see this stuff? Nearly every one of the > lists hosted on vger.kernel.org get spammed on a regular basis because > there is no spam filtering before the messages get passed to majordomo. Are we reading different mailing lists ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add "bus" symlink to class/block devices
On Tue, Feb 15, 2005 at 11:04:06PM +0100, Kay Sievers wrote: > On Tue, Feb 15, 2005 at 09:53:44PM +0100, Kay Sievers wrote: > > Add a "bus" symlink to the class and block devices, just like the "driver" > > and "device" links. This may be a huge speed gain for e.g. udev to determine > > the bus value of a device, as we currently need to do a brute-force scan in > > /sys/bus/* to find this value. > > Hmm, while playing around with it, I think we should create the "bus" > link on the physical device on not on the class device. > > Also the current "driver" link at the class device should be removed, > cause class devices don't have a driver. Block devices never had this > misleading symlink. > > >From the class device we point with the "device" link to the physical > device, and only the physical device should have the "driver" and the > "bus" link, as it represents the real relationship. Applied, 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/
Re: "Needlessly global functions static...."
On Dunnersdag 17 Februar 2005 22:25, Chris Wright wrote: > static != inline. Locally scoped symbols, 't', and global, 'T', > are in kallsyms or System.map. Well, actually they might get inlined automatically when building with gcc -funit-at-a-time. That is of course a desired side effect of making symbols local, although it can be confusing when you're looking at the assembler output. Arnd <>< pgpjxKOccTYB7.pgp Description: signature
Re: E-cards for You
On Thu, 17 Feb 2005, Gene Heskett wrote: On Thursday 17 February 2005 16:20, James Colannino wrote: [EMAIL PROTECTED] wrote: Greetings! has sent you an E-Card -- a virtual postcard from TheArtHaven.com. You can pickup your card at the TheArtHaven.com website. This is the first time I've ever seen someone send an e-card to a mailing list... Not here, its entirely too common of late. Spamassassin to the rescue... James Why can't the list owners apply spamassassin to the list's *incoming* mail stream so we don't ever see this stuff? Nearly every one of the lists hosted on vger.kernel.org get spammed on a regular basis because there is no spam filtering before the messages get passed to majordomo. -- Charles D. (Chuck) Harding <[EMAIL PROTECTED]> Voice: 925-423-8879 Senior Computer Associate ICCDFax: 925-423-8719 Lawrence Livermore National Laboratory Computation Directorate Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601 -- http://tinyurl.com/5w5ey --- -- An unemployed court jester is no one's fool. -- - 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] Altix : ioc4 serial driver support
Andrew, Since there don't seem to be any more suggestions, can you take this - or at least queue it up ??? This is a resend: I updated again with more __iomem tags. ftp://oss.sgi.com/projects/sn2/sn2-update/033-ioc4-support Signed-off-by: Patrick Gefre <[EMAIL PROTECTED]> Christoph Hellwig wrote: On Thu, Feb 10, 2005 at 11:09:43AM -0800, Jesse Barnes wrote: On Tuesday, February 8, 2005 8:52 am, Patrick Gefre wrote: I've update the patch with changes from the comments below. ftp://oss.sgi.com/projects/sn2/sn2-update/033-ioc4-support Christoph Hellwig wrote: On Mon, Feb 07, 2005 at 09:58:33AM -0600, Patrick Gefre wrote: Latest version with review mods: ftp://oss.sgi.com/projects/sn2/sn2-update/033-ioc4-support - still not __iomem annotations. I *think* I have this right ?? Here's the output from 'make C=1' with your driver patched in (you if you want to run it yourself, just copy tomahawk.engr:~jbarnes/bin/sparse to somewhere in your path and run 'make C=1'). I think most of these warning would be fixed up if the structure fields referring to registers were declared as __iomem, but I haven't looked carefully. Actually the pointers to the struct need to be declared __iomem. - 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: E-cards for You
On Thursday 17 February 2005 16:20, James Colannino wrote: >[EMAIL PROTECTED] wrote: >>Greetings! >> >> has sent you an E-Card -- a virtual postcard from >>TheArtHaven.com. You can pickup your card at the TheArtHaven.com >> website. > >This is the first time I've ever seen someone send an e-card to a >mailing list... > Not here, its entirely too common of late. Spamassassin to the rescue... >James -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.33% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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] yaird, a mkinitrd based on hotplug concepts
Erik van Konijnenburg wrote: Features: - handles both initrd and initramfs. Comments: * Having a mkinitrd that's not a shell script is a godsend. I would endorse yaird on that fact alone :) * I've long wanted a "mkinitfoo" that would create .cpio.gz for initramfs by default. So, good job there, too. * Eventually your script will need pull in, into the initramfs, klibc and programs linked against klibc. 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: [OOPS] 2.6.10, ReiserFS errors, preempt
Hello On Thu, 17 Feb 2005 [EMAIL PROTECTED] wrote: > > I believe there's unresolved memory corruption bug in bttv... > yes I think so, other have also similar problem : > http://marc.theaimsgroup.com/?l=linux-kernel&m=110820804010204&w=2 > http://marc.theaimsgroup.com/?t=11053154392&r=1&w=2 > http://www.ussg.iu.edu/hypermail/linux/kernel/0412.3/0881.html Ahh... /me stops the memory test after 18 hours without a single error, pulls the card out of my desktop and inserts it back into the experimantal machine. Unfortunately, unlike in other posts you quoted above, I cannot reproduce my Oops. Is anybody working on this? Thanks Guennadi --- Guennadi Liakhovetski - 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: [BK] upgrade will be needed
* David Weinehall ([EMAIL PROTECTED]) wrote: > BTW: Wishlist request. Would you consider adding -p (--show-c-function) > to the set of flags used for the diffs created by BitKeeper? It's already there. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - 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] add umask parameter to procfs
Add proc.umask kernel parameter. It can be used to restrict permissions on the numerical directories in the root of a proc filesystem, i.e. the directories containing process specific information. E.g. add proc.umask=077 to your kernel command line and all users except root can only see their own process details (like command line parameters) with ps or top. It can be useful to add a bit of privacy to multi-user servers. The patch has been inspired by a similar feature in GrSecurity. It could have also been implemented as a mount option to procfs, but at a higher cost and no apparent benefit -- changes to this umask are not supposed to happen very often. Actually, the previous incarnation of this patch was implemented as a half-assed mount option, but I didn't know then how easy it is to add a kernel parameter. Comments about usefulness or implementation are very welcome. Thanks, Rene --- linux-2.6.11-rc4/fs/proc/base.c~2005-02-11 21:16:13.0 +0100 +++ linux-2.6.11-rc4/fs/proc/base.c 2005-02-11 23:38:17.0 +0100 @@ -32,8 +32,14 @@ #include #include #include +#include +#include #include "internal.h" +static umode_t umask = 0; +module_param(umask, ushort, 0); +MODULE_PARM_DESC(umask, "umask for the numerical directories in /proc"); + /* * For hysterical raisins we keep the same inumbers as in the old procfs. * Feel free to change the macro below - just keep the range distinct from @@ -1369,7 +1375,7 @@ static struct dentry *proc_pident_lookup goto out; ei = PROC_I(inode); - inode->i_mode = p->mode; + inode->i_mode = p->mode & ~(umask & S_IRWXUGO); /* * Yes, it does not scale. And it should not. Don't add * new entries into /proc// without very good reasons. @@ -1699,7 +1705,7 @@ struct dentry *proc_pid_lookup(struct in put_task_struct(task); goto out; } - inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO; + inode->i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) & ~umask); inode->i_op = &proc_tgid_base_inode_operations; inode->i_fop = &proc_tgid_base_operations; inode->i_nlink = 3; @@ -1754,7 +1760,7 @@ static struct dentry *proc_task_lookup(s if (!inode) goto out_drop_task; - inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO; + inode->i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) & ~umask); inode->i_op = &proc_tid_base_inode_operations; inode->i_fop = &proc_tid_base_operations; inode->i_nlink = 3; - 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] remove mount option parsing from procfs
OK, my previous patches on the subject were _so_ bad that noone even
bothered to flame me. Here's an attempt to fix this. :]
This patch removes the mount options of the proc filesystem. They don't
have any effect since 2.4.something.
Explanation: Only proc_fill_super() calls parse_options, notably
proc_remount() does not. And proc_fill_super() is only called at the
very first mount which in turn is the one caused by kern_mount() in
fs/proc/root.c and that passes a NULL pointer as mount options
string. It is called only once because proc is a filesystem with a
single super_block (i.e. it uses get_sb_single()).
Since noone seems to miss the uid and gid options so far I suggest to
simply remove them. Their function can be easily performed in
userspace. E.g. this (if it worked like intended):
# mount -t proc -o uid=procuser,gid=procgrp proc /proc
can be done like so, probably in some init script:
# mount -t proc proc /proc && chown procuser:procgrp /proc
But I don't see why anyone would want to do that in the first place.
Comments?
Rene
--- linux-2.6.11-rc4/fs/proc/inode.c~ 2005-02-05 03:21:58.0 +0100
+++ linux-2.6.11-rc4/fs/proc/inode.c2005-02-11 05:33:47.0 +0100
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
@@ -143,51 +142,6 @@ static struct super_operations proc_sops
.remount_fs = proc_remount,
};
-enum {
- Opt_uid, Opt_gid, Opt_err
-};
-
-static match_table_t tokens = {
- {Opt_uid, "uid=%u"},
- {Opt_gid, "gid=%u"},
- {Opt_err, NULL}
-};
-
-static int parse_options(char *options,uid_t *uid,gid_t *gid)
-{
- char *p;
- int option;
-
- *uid = current->uid;
- *gid = current->gid;
- if (!options)
- return 1;
-
- while ((p = strsep(&options, ",")) != NULL) {
- substring_t args[MAX_OPT_ARGS];
- int token;
- if (!*p)
- continue;
-
- token = match_token(p, tokens, args);
- switch (token) {
- case Opt_uid:
- if (match_int(args, &option))
- return 0;
- *uid = option;
- break;
- case Opt_gid:
- if (match_int(args, &option))
- return 0;
- *gid = option;
- break;
- default:
- return 0;
- }
- }
- return 1;
-}
-
struct inode *proc_get_inode(struct super_block *sb, unsigned int ino,
struct proc_dir_entry *de)
{
@@ -249,10 +203,11 @@ int proc_fill_super(struct super_block *
* Fixup the root inode's nlink value
*/
root_inode->i_nlink += nr_processes();
+ root_inode->i_uid = 0;
+ root_inode->i_gid = 0;
s->s_root = d_alloc_root(root_inode);
if (!s->s_root)
goto out_no_root;
- parse_options(data, &root_inode->i_uid, &root_inode->i_gid);
return 0;
out_no_root:
-
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: [BK] upgrade will be needed
On Thu, February 17, 2005 3:52 pm, Horst von Brand said: > "Best tool for the job" certainly includes minutiae like "benefits" and > "price". Thank you, that's my point. It's not just about the geeky microscopic technical details. Sean - 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: "Needlessly global functions static...."
* linux-os ([EMAIL PROTECTED]) wrote: > > Hello, > Tell me. When all those kernel functions are made static > how does one use a kernel debugger? How does the OOPS > get decoded if nothing is in /proc/kallsyms or System.map??? static != inline. Locally scoped symbols, 't', and global, 'T', are in kallsyms or System.map. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - 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: "Needlessly global functions static...."
linux-os> Hello, Tell me. When all those kernel functions are made linux-os> static how does one use a kernel debugger? How does the linux-os> OOPS get decoded if nothing is in /proc/kallsyms or linux-os> System.map??? Dude, static symbols are still in System.map and /proc/kallsyms. - 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: E-cards for You
[EMAIL PROTECTED] wrote: Greetings! has sent you an E-Card -- a virtual postcard from TheArtHaven.com. You can pickup your card at the TheArtHaven.com website. This is the first time I've ever seen someone send an e-card to a mailing list... 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: [BK] upgrade will be needed
"Sean" <[EMAIL PROTECTED]> said: > On Thu, February 17, 2005 11:55 am, Chris Friesen said: > > If you look at the archives, there have been a *lot* of people saying > > very much the same thing as you. I suspect people are getting tired of > > giving the same responses all the time. > > > > Here is what Linus had to say about it a while back: > > > > If people in the open-source SCM community wake up and notice that > > the current open-source SCM systems aren't cutting it, that's _good_. > > But it's absolutely NOT an excuse to use them today. Sorry. I use > > CVS at work, and I could never use it for Linux. I took a look at > > subversion, and it doesn't even come close to what I wanted. > > > > And I personally refuse to use inferior tools because of ideology. In > > fact, I will go as far as saying that making excuses for bad tools > > due to ideology is _stupid_, and people who do that think with their > > gonads, not their brains. > Yes, I do remember that post. But i'm not arguing from an ideological > basis; i'm arguing on practical grounds that the price of using BK is too > high for its supposed benefits. "Best tool for the job" certainly includes minutiae like "benefits" and "price". > I've not seen anyone else make that > argument here on the list and it is something that Linus may not have > given full consideration to. At least the comment that you quote gives > no consideration to it at all. It doesn't do so overtly, no. Doesn't mean it wasn't part of the equation. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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/
"Needlessly global functions static...."
Hello, Tell me. When all those kernel functions are made static how does one use a kernel debugger? How does the OOPS get decoded if nothing is in /proc/kallsyms or System.map??? Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - 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 patch] drivers/net/starfire.c
See http://bugme.osdl.org/show_bug.cgi?id=4208 for all relevant information. -- --- drivers/net/starfire.c.old 2005-02-17 04:12:20.987861182 -0600 +++ drivers/net/starfire.c 2005-02-17 04:11:55.038499137 -0600 @@ -271,7 +271,7 @@ * This SUCKS. * We need a much better method to determine if dma_addr_t is 64-bit. */ -#if (defined(__i386__) && defined(CONFIG_HIGHMEM) && (LINUX_VERSION_CODE > 0x20500 || defined(CONFIG_HIGHMEM64G))) || defined(__x86_64__) || defined (__ia64__) || defined(__mips64__) || (defined(__mips__) && defined(CONFIG_HIGHMEM) && defined(CONFIG_64BIT_PHYS_ADDR)) +#if (defined(__i386__) && defined(CONFIG_HIGHMEM64G)) || defined(__x86_64__) || defined (__ia64__) || defined(__mips64__) || (defined(__mips__) && defined(CONFIG_HIGHMEM) && defined(CONFIG_64BIT_PHYS_ADDR)) /* 64-bit dma_addr_t */ #define ADDR_64BITS/* This chip uses 64 bit addresses. */ #define cpu_to_dma(x) cpu_to_le64(x) @@ -1401,7 +1401,7 @@ } if (has_bad_length) - skb_checksum_help(skb); + skb_checksum_help(skb, 0); } #endif /* ZEROCOPY && HAS_BROKEN_FIRMWARE */ - 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 patch] drivers/net/loopback.c: make a function static
This patch makes a needlessly global function static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--
--- linux-2.6.11-rc3-mm2-full/drivers/net/loopback.c.old2005-02-16
16:08:04.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/loopback.c2005-02-16
16:08:14.0 +0100
@@ -184,7 +184,7 @@
return stats;
}
-u32 loopback_get_link(struct net_device *dev)
+static u32 loopback_get_link(struct net_device *dev)
{
return 1;
}
-
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 patch] drivers/net/ixgb/: possible cleanups
This patch contains the following possible cleanups:
- make needlessly global code static
- remove the following unused global functions:
- ixgb_ee.c: ixgb_get_ee_compatibility
- ixgb_ee.c: ixgb_get_ee_init_ctrl_reg_1
- ixgb_ee.c: ixgb_get_ee_init_ctrl_reg_2
- ixgb_ee.c: ixgb_get_ee_subsystem_id
- ixgb_ee.c: ixgb_get_ee_subvendor_id
- ixgb_ee.c: ixgb_get_ee_vendor_id
- ixgb_ee.c: ixgb_get_ee_swdpins_reg
- ixgb_ee.c: ixgb_get_ee_d3_power
- ixgb_ee.c: ixgb_get_ee_d0_power
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_ee.c | 170
drivers/net/ixgb/ixgb_ethtool.c |2
drivers/net/ixgb/ixgb_hw.c | 26 +++-
drivers/net/ixgb/ixgb_hw.h | 26
drivers/net/ixgb/ixgb_main.c|6 -
5 files changed, 21 insertions(+), 209 deletions(-)
--- linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_hw.h.old2005-02-16
15:55:21.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_hw.h2005-02-16
16:06:28.0 +0100
@@ -784,23 +784,8 @@
extern boolean_t ixgb_adapter_stop(struct ixgb_hw *hw);
extern boolean_t ixgb_init_hw(struct ixgb_hw *hw);
extern boolean_t ixgb_adapter_start(struct ixgb_hw *hw);
-extern void ixgb_init_rx_addrs(struct ixgb_hw *hw);
extern void ixgb_check_for_link(struct ixgb_hw *hw);
extern boolean_t ixgb_check_for_bad_link(struct ixgb_hw *hw);
-extern boolean_t ixgb_setup_fc(struct ixgb_hw *hw);
-extern void ixgb_clear_hw_cntrs(struct ixgb_hw *hw);
-extern boolean_t mac_addr_valid(uint8_t *mac_addr);
-
-extern uint16_t ixgb_read_phy_reg(struct ixgb_hw *hw,
- uint32_t reg_addr,
- uint32_t phy_addr,
- uint32_t device_type);
-
-extern void ixgb_write_phy_reg(struct ixgb_hw *hw,
- uint32_t reg_addr,
- uint32_t phy_addr,
- uint32_t device_type,
- uint16_t data);
extern void ixgb_rar_set(struct ixgb_hw *hw,
uint8_t *addr,
@@ -818,21 +803,10 @@
uint32_t offset,
uint32_t value);
-extern void ixgb_clear_vfta(struct ixgb_hw *hw);
-
/* Access functions to eeprom data */
void ixgb_get_ee_mac_addr(struct ixgb_hw *hw, uint8_t *mac_addr);
-uint16_t ixgb_get_ee_compatibility(struct ixgb_hw *hw);
uint32_t ixgb_get_ee_pba_number(struct ixgb_hw *hw);
-uint16_t ixgb_get_ee_init_ctrl_reg_1(struct ixgb_hw *hw);
-uint16_t ixgb_get_ee_init_ctrl_reg_2(struct ixgb_hw *hw);
-uint16_t ixgb_get_ee_subsystem_id(struct ixgb_hw *hw);
-uint16_t ixgb_get_ee_subvendor_id(struct ixgb_hw *hw);
uint16_t ixgb_get_ee_device_id(struct ixgb_hw *hw);
-uint16_t ixgb_get_ee_vendor_id(struct ixgb_hw *hw);
-uint16_t ixgb_get_ee_swdpins_reg(struct ixgb_hw *hw);
-uint8_t ixgb_get_ee_d3_power(struct ixgb_hw *hw);
-uint8_t ixgb_get_ee_d0_power(struct ixgb_hw *hw);
boolean_t ixgb_get_eeprom_data(struct ixgb_hw *hw);
uint16_t ixgb_get_eeprom_word(struct ixgb_hw *hw, uint16_t index);
--- linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_ee.c.old2005-02-16
15:55:34.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/ixgb/ixgb_ee.c2005-02-16
15:58:37.0 +0100
@@ -560,25 +560,6 @@
}
/**
- * return the compatibility flags from EEPROM
- *
- * hw - Struct containing variables accessed by shared code
- *
- * Returns:
- * compatibility flags if EEPROM contents are valid, 0 otherwise
-
**/
-uint16_t
-ixgb_get_ee_compatibility(struct ixgb_hw *hw)
-{
- struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;
-
- if(ixgb_check_and_get_eeprom_data(hw) == TRUE)
- return(ee_map->compatibility);
-
- return(0);
-}
-
-/**
* return the Printed Board Assembly number from EEPROM
*
* hw - Struct containing variables accessed by shared code
@@ -597,82 +578,6 @@
}
/**
- * return the Initialization Control Word 1 from EEPROM
- *
- * hw - Struct containing variables accessed by shared code
- *
- * Returns:
- * Initialization Control Word 1 if EEPROM contents are valid, 0
otherwise
-
**/
-uint16_t
-ixgb_get_ee_init_ctrl_reg_1(struct ixgb_hw *hw)
-{
- struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom;
-
- if(ixgb_check_and_get_eeprom_data(hw) == TRUE)
- return(ee_map->init_ctrl_reg_1);
-
- return(0);
-}
-
-/**
- * return the
[2.6 patch] drivers/net/lp486e.c: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/lp486e.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
--- linux-2.6.11-rc3-mm2-full/drivers/net/lp486e.c.old 2005-02-16
16:08:34.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/lp486e.c 2005-02-16
16:15:33.0 +0100
@@ -112,8 +112,10 @@
CmdDiagnose = 7
};
-char *CUcmdnames[8] = { "NOP", "IASetup", "Configure", "MulticastList",
- "Tx", "TDR", "Dump", "Diagnose" };
+#if 0
+static char *CUcmdnames[8] = { "NOP", "IASetup", "Configure", "MulticastList",
+ "Tx", "TDR", "Dump", "Diagnose" };
+#endif
/* Status word bits */
#defineSTAT_CX 0x8000 /* The CU finished executing a command
@@ -960,7 +962,7 @@
(unsigned char) add[12], (unsigned char) add[13]);
}
-int __init lp486e_probe(struct net_device *dev) {
+static int __init lp486e_probe(struct net_device *dev) {
struct i596_private *lp;
unsigned char eth_addr[6] = { 0, 0xaa, 0, 0, 0, 0 };
unsigned char *bios;
-
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: [ACPI] Call for help: list of machines with working S3
Am Donnerstag, 17. Februar 2005 20:08 schrieb Norbert Preining: > On Die, 15 Feb 2005, Stefan Dösinger wrote: > > > - DRI must be disabled I guess?! Even with newer X server (x.org)? > > > > Do you use the fglrx driver? This doesn't work with any type of suspend > > so far. If you use the radeon driver try a driver update. > > Ok, I installed xlibmesa-gl1-dri-trunk, xserver-xfree86-dri-trunk and > compiled linux-2.6.11-rc4 and drm modules from drm-trunk-module-src, all > from http://www.nixnuts.net/files/ > > But I had no success whatsoever. With this (Xorg server, current dri/drm > stuff, ..) the laptop not even wakes up from sleep! Sorry, no Idea. What about 2.6.11-rc3-mm2 + Xorg 6.8.1.99? Did you test this combination? Am I right with assuming that resumeworked after the X upgrade if X wasn't started before suspend? Stefan - 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.10-ac12 + kernbench == oom-killer: (OSDL)
On Wed, 9 Feb 2005 10:12:06 -0200 Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > On Tue, Feb 08, 2005 at 02:57:07PM -0800, cliff white wrote: > > > > Running 2.6.10-ac10 on the STP 1-CPU machines, we don't seem to be able to > > complete > > a kernbench run without hitting the OOM-killer. ( kernbench is multiple > > kernel compiles, > > of course ) Machine is 800 mhz PIII with 1GB memory. We reduce memory for > > some of the runs. > > Cliff, > > Please try recent v2.6.11-rc3, they include a series of OOM killer fixes from > Andrea et all. > Sorry for the delay in response. Recent -bk runs still show this problem, for example: http://khack.osdl.org/stp/300713/logs/TestRunFailed.console.log.txt ( patch-2.6.11-rc3-bk4 ) cliffw > Thanks. > -- "Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason." -Michael Feldman - 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/
