Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
Thanks for your comments, Alexey. I've now incorprorated all of the requested changes and am testing the driver. If everything is still fine, I'll repost later today. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpCUESmjveeW.pgp Description: PGP signature
Re: [Linux-cluster] Re: GFS, what's remaining
Mark Fasheh <[EMAIL PROTECTED]> wrote: > > On Sat, Sep 03, 2005 at 09:46:53PM -0700, Andrew Morton wrote: > > Actually I think it's rather sick. Taking O_NONBLOCK and making it a > > lock-manager trylock because they're kinda-sorta-similar-sounding? Spare > > me. O_NONBLOCK means "open this file in nonblocking mode", not "attempt to > > acquire a clustered filesystem lock". Not even close. > > What would be an acceptable replacement? I admit that O_NONBLOCK -> trylock > is a bit unfortunate, but really it just needs a bit to express that - > nobody over here cares what it's called. The whole idea of reinterpreting file operations to mean something utterly different just seems inappropriate to me. You get a lot of goodies when using a filesystem - the ability for unrelated processes to look things up, resource release on exit(), etc. If those features are valuable in the ocfs2 context then fine. But I'd have thought that it would be saner and more extensible to add new syscalls (perhaps taking fd's) rather than overloading the open() mode in this manner. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: i386: kill !4KSTACKS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lee Revell wrote: > On Fri, 2005-09-02 at 02:39 +0200, Adrian Bunk wrote: > >>4Kb kernel stacks are the future on i386, and it seems the problems it >>initially caused are now sorted out. >> >>Does anyone knows about any currently unsolved problems? > > > ndiswrapper While I agree ndiswrapper has a use ... I don't think we should base kernel development upon messing with something that is designed to run a windows driver in linux ... // Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDGqPiBrn2kJu9P78RAgO4AJ9r6FNwB+72iRmdcMoxP0vi8gTDUQCfeUG5 5Qbcq/o/Zao79JPEVqOmH+M= =xpUz -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: [Linux-cluster] Re: GFS, what's remaining
Daniel Phillips <[EMAIL PROTECTED]> wrote: > > If the only user is their tools I would say let it go ahead and be cute, even > sickeningly so. It is not supposed to be a general dlm api, at least that > is > my understanding. It is just supposed to be an interface for their tools. > Of course it would help to know exactly how those tools use it. Well I'm not saying "don't do this". I'm saying "eww" and "why?". If there is already a richer interface into all this code (such as a syscall one) and it's feasible to migrate the open() tricksies to that API in the future if it all comes unstuck then OK. That's why I asked (thus far unsuccessfully): Are you saying that the posix-file lookalike interface provides access to part of the functionality, but there are other APIs which are used to access the rest of the functionality? If so, what is that interface, and why cannot that interface offer access to 100% of the functionality, thus making the posix-file tricks unnecessary? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] New: Omnikey CardMan 4040 PCMCIA Driver
Hi Nish, thanks for your comments. On Sat, Sep 03, 2005 at 03:13:43PM -0700, Nish Aravamudan wrote: > On 9/3/05, Chase Venters <[EMAIL PROTECTED]> wrote: > > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA > > > Smartcard Reader. > > > > #define CCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) > > These are all fine. Although I am a bit suspicious of 150 second > timeouts; but if that is the hardware... That's a definition from the original vendor-supplied driver. Unfortunately there's no hardware documentation, so I can't verify it. But generally speaking, serial smart cards can really be slow, so I think it could make sense. > > /* how often to poll for fifo status change */ > > #define POLL_PERIOD (HZ/100) > > This needs to be msecs_to_jiffies(10), please. thanks, changed in my local tree now. > Of bigger concern to me is the use of the sleep_on() family of > functions, all of which are deprecated. Ok, I'm working on replacing the respective code with wait_event_interruptible_timeout(). -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpjkUFyNclXx.pgp Description: PGP signature
Re: forbid to strace a program
Chase Venters wrote: >> Is there another way to do this? If the password is crypted, I need a >> passphrase or something other to decrypt it again. Not really a solution >> of the problem. >> >> Therefore, it would be best, to hide it by preventing stracing of the >> application to all users and root. >> >> Ok, root could search for the password directly in the memory, but this >> would be not as easy as a strace. > > Obfuscation isn't really valid security. Making something 'harder' to break > isn't a solution unless you're making it hard enough that current technology > can't break it (eg... you always have the brute force option, but good crypto > intends to make such an option impossible without expending zillions of clock > cycles). You're right. If I would have a solution, which could do this, I would prefer it. > > Can I ask why you want to hide the database password from root? It's easy: for security reasons. There could always be some bugs in some software, which makes it possible for some other user, to gain root privileges. Now, they could easily strace for information, they shouldn't could do it. The password they could see, isn't just used for the DB, but for some other applications, too. That's the disadvantage of general (single sign on) passwords. Kind regards, Andreas Hartmann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
On Sun, Sep 04, 2005 at 12:28:28AM -0700, Andrew Morton wrote: > If there is already a richer interface into all this code (such as a > syscall one) and it's feasible to migrate the open() tricksies to that API > in the future if it all comes unstuck then OK. > That's why I asked (thus far unsuccessfully): I personally was under the impression that "syscalls are not to be added". I'm also wary of the effort required to hook into process exit. Not to mention all the lifetiming that has to be written again. On top of that, we lose our cute ability to shell script it. We find this very useful in testing, and think others would in practice. >Are you saying that the posix-file lookalike interface provides >access to part of the functionality, but there are other APIs which are >used to access the rest of the functionality? If so, what is that >interface, and why cannot that interface offer access to 100% of the >functionality, thus making the posix-file tricks unnecessary? I thought I stated this in my other email. We're not intending to extend dlmfs. It pretty much covers the simple DLM usage required of a simple interface. The OCFS2 DLM does not provide any other functionality. If the OCFS2 DLM grew more functionality, or you consider the GFS2 DLM that already has it (and a less intuitive interface via sysfs IIRC), I would contend that dlmfs still has a place. It's simple to use and understand, and it's usable from shell scripts and other simple code. Joel -- "The first thing we do, let's kill all the lawyers." -Henry VI, IV:ii Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Brand-new notebook useless with Linux...
On 9/4/05, Paul Misner <[EMAIL PROTECTED]> wrote:
> On Saturday 03 September 2005 5:58 pm, Chuck Ebbert wrote:
> > I just bought a new notebook. Here is the output from lspci using the
> > latest pci.ids file from sourceforge:
> >
> ...
> > controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g
> > Wireless LAN Controller (rev 02) 05:09.0 CardBus bridge: Texas Instruments
> > 05:09.4 Class 0805: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621,
> > PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller
> >
> > None of these work and I can find no support anywhere for them:
> >
> > SMBus
> > Audio ("unknown codec")
> > Modem ("no codec available")
> > Wireless
> > FlashMedia
> > SD/MMC
> >
> > Additionally, the system clock runs at 2x normal speed with PowerNow
> > enabled.
> >
> > Am I stuck with running XP on this thing?
> >
> > __
> > Chuck
> > -
>
> >You already had an answer on the audio. Your answer on the wireless is
> >ndiswrapper. You should really be looking at the Linux r3000 list, which
> >handles much more than that now. The information for that list is:
> >
> >LinuxR3000 mailing list
> >LinuxR3000@lists.pcxperience.com
> > http://lists.pcxperience.com/cgi-bin/mailman/listinfo/linuxr3000
> >Wiki at http://prinsig.se/weekee/
Or help to rewrite from scracth broadcom drivers see
http://bcm-specs.sipsolutions.net/ for the specs. Unfortunatly, I have
no time to do this but I expect somebody have...
> >If those folks don't know how to make you notebook run, you are in serious
> >trouble. I have a Compaq R3120US, which I learned how to set up from the
> >people over there. Notebooks are very different from most other computers,
> >and you can expect to take some extra time and effort to get one set up.
>
> >An important note about your wireless is that even with ndiswrapper, not all
> >Windows drivers are created equal, and you may need to try several for the
> >same chip from different sources to find one that works.
>
> >Good luck with your SD/MMC reader, that tends to be something that doesn't
> >work under Linux because the manufacturers haven't released the information
> >needed to create proper drivers for them.
>
> >Mandriva tends to work great on notebooks, once you install the proper
> >wireless driver, I have had good luck with Mepis as well, and I know many
> >people running Fedora as well. Your other big challenge, maybe the biggest
> >one, is going to be the display, at least if you have an uncommon display
> >like the 1280 X 800 on my notebook.
>
> >Paul
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: [Linux-cluster] Re: GFS, what's remaining
On Sun, Sep 04, 2005 at 12:23:43AM -0700, Andrew Morton wrote: > > What would be an acceptable replacement? I admit that O_NONBLOCK -> trylock > > is a bit unfortunate, but really it just needs a bit to express that - > > nobody over here cares what it's called. > > The whole idea of reinterpreting file operations to mean something utterly > different just seems inappropriate to me. Putting aside trylock for a minute, I'm not sure how utterly different the operations are. You create a lock resource by creating a file named after it. You get a lock (fd) at read or write level on the resource by calling open(2) with the appropriate mode (O_RDONLY, O_WRONLY/O_RDWR). Now that we've got an fd, lock value blocks are naturally represented as file data which can be read(2) or written(2). Close(2) drops the lock. A really trivial usage example from shell: node1$ echo "hello world" > mylock node2$ cat mylock hello world I could always give a more useful one after I get some sleep :) > You get a lot of goodies when using a filesystem - the ability for > unrelated processes to look things up, resource release on exit(), etc. If > those features are valuable in the ocfs2 context then fine. Right, they certainly are and I think Joel, in another e-mail on this thread, explained well the advantages of using a filesystem. > But I'd have thought that it would be saner and more extensible to add new > syscalls (perhaps taking fd's) rather than overloading the open() mode in > this manner. The idea behind dlmfs was to very simply export a small set of cluster dlm operations to userspace. Given that goal, I felt that a whole set of system calls would have been overkill. That said, I think perhaps I should clarify that I don't intend dlmfs to become _the_ userspace dlm api, just a simple and (imho) intuitive one which could be trivially accessed from any software which just knows how to read and write files. --Mark -- Mark Fasheh Senior Software Developer, Oracle [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: Kernel 2.6.13 breaks libpcap (and tcpdump).
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>> Filter incoming data, looking for ICMP messages:
>>
>> tcpdump -f "ip proto \icmp"
>>
>> Well, that catches nothing.
We aren't handling the reading of specific fields like the IP protocol
field correctly. This patch should make it work again.
I tried to move this logic into the new load_pointer function but it
all came out messy so I simply rolled it back.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/core/filter.c b/net/core/filter.c
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -36,7 +36,7 @@
#include
/* No hurry in this branch */
-static void *__load_pointer(struct sk_buff *skb, int k)
+static void *load_pointer(struct sk_buff *skb, int k)
{
u8 *ptr = NULL;
@@ -50,18 +50,6 @@ static void *__load_pointer(struct sk_bu
return NULL;
}
-static inline void *load_pointer(struct sk_buff *skb, int k,
- unsigned int size, void *buffer)
-{
- if (k >= 0)
- return skb_header_pointer(skb, k, size, buffer);
- else {
- if (k >= SKF_AD_OFF)
- return NULL;
- return __load_pointer(skb, k);
- }
-}
-
/**
* sk_run_filter - run a filter on a socket
* @skb: buffer to run the filter on
@@ -177,7 +165,13 @@ int sk_run_filter(struct sk_buff *skb, s
case BPF_LD|BPF_W|BPF_ABS:
k = fentry->k;
load_w:
- ptr = load_pointer(skb, k, 4, &tmp);
+ if (k >= 0)
+ ptr = skb_header_pointer(skb, k, 4, &tmp);
+ else if (k < SKF_AD_OFF)
+ ptr = load_pointer(skb, k);
+ else
+ break;
+
if (ptr != NULL) {
A = ntohl(*(u32 *)ptr);
continue;
@@ -186,7 +180,13 @@ int sk_run_filter(struct sk_buff *skb, s
case BPF_LD|BPF_H|BPF_ABS:
k = fentry->k;
load_h:
- ptr = load_pointer(skb, k, 2, &tmp);
+ if (k >= 0)
+ ptr = skb_header_pointer(skb, k, 2, &tmp);
+ else if (k < SKF_AD_OFF)
+ ptr = load_pointer(skb, k);
+ else
+ break;
+
if (ptr != NULL) {
A = ntohs(*(u16 *)ptr);
continue;
@@ -195,7 +195,13 @@ int sk_run_filter(struct sk_buff *skb, s
case BPF_LD|BPF_B|BPF_ABS:
k = fentry->k;
load_b:
- ptr = load_pointer(skb, k, 1, &tmp);
+ if (k >= 0)
+ ptr = skb_header_pointer(skb, k, 1, &tmp);
+ else if (k < SKF_AD_OFF)
+ ptr = load_pointer(skb, k);
+ else
+ break;
+
if (ptr != NULL) {
A = *(u8 *)ptr;
continue;
@@ -217,7 +223,9 @@ load_b:
k = X + fentry->k;
goto load_b;
case BPF_LDX|BPF_B|BPF_MSH:
- ptr = load_pointer(skb, fentry->k, 1, &tmp);
+ if (fentry->k < 0)
+ return 0;
+ ptr = skb_header_pointer(skb, fentry->k, 1, &tmp);
if (ptr != NULL) {
X = (*(u8 *)ptr & 0xf) << 2;
continue;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
Joel Becker <[EMAIL PROTECTED]> wrote:
>
> On Sun, Sep 04, 2005 at 12:28:28AM -0700, Andrew Morton wrote:
> > If there is already a richer interface into all this code (such as a
> > syscall one) and it's feasible to migrate the open() tricksies to that API
> > in the future if it all comes unstuck then OK.
> > That's why I asked (thus far unsuccessfully):
>
> I personally was under the impression that "syscalls are not
> to be added".
We add syscalls all the time. Whichever user<->kernel API is considered to
be most appropriate, use it.
> I'm also wary of the effort required to hook into process
> exit.
I'm not questioning the use of a filesystem. I'm questioning this
overloading of normal filesystem system calls. For example (and this is
just an example! there's also mknod, mkdir, O_RDWR, O_EXCL...) it would be
more usual to do
fd = open("/sys/whatever", ...);
err = sys_dlm_trylock(fd);
I guess your current implementation prevents /sys/whatever from ever
appearing if the trylock failed. Dunno if that's valuable.
> Not to mention all the lifetiming that has to be written again.
> On top of that, we lose our cute ability to shell script it. We
> find this very useful in testing, and think others would in practice.
>
> >Are you saying that the posix-file lookalike interface provides
> >access to part of the functionality, but there are other APIs which are
> >used to access the rest of the functionality? If so, what is that
> >interface, and why cannot that interface offer access to 100% of the
> >functionality, thus making the posix-file tricks unnecessary?
>
> I thought I stated this in my other email. We're not intending
> to extend dlmfs.
Famous last words ;)
> It pretty much covers the simple DLM usage required of
> a simple interface. The OCFS2 DLM does not provide any other
> functionality.
> If the OCFS2 DLM grew more functionality, or you consider the
> GFS2 DLM that already has it (and a less intuitive interface via sysfs
> IIRC), I would contend that dlmfs still has a place. It's simple to use
> and understand, and it's usable from shell scripts and other simple
> code.
(wonders how to do O_NONBLOCK from a script)
I don't buy the general "fs is nice because we can script it" argument,
really. You can just write a few simple applications which provide access
to the syscalls (or the fs!) and then write scripts around those.
Yes, you suddenly need to get a little tarball into users' hands and that's
a hassle. And I sometimes think we let this hassle guide kernel interfaces
(mutters something about /sbin/hotplug), and that's sad.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: i386: kill !4KSTACKS
On Sun, 2005-09-04 at 09:36 +0200, Stefan Smietanowski wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Lee Revell wrote: > > On Fri, 2005-09-02 at 02:39 +0200, Adrian Bunk wrote: > > > >>4Kb kernel stacks are the future on i386, and it seems the problems it > >>initially caused are now sorted out. > >> > >>Does anyone knows about any currently unsolved problems? > > > > > > ndiswrapper > > While I agree ndiswrapper has a use ... I don't think we should > base kernel development upon messing with something that is designed > to run a windows driver in linux ... Good point, but I don't think we should needlessly render people's hardware inoperable either. 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: Potential IPSec DoS/Kernel Panic with 2.6.13
Matt LaPlante <[EMAIL PROTECTED]> wrote:
>
> network connectivity on my router. Upon further inspection I noticed the
> packet had actually caused a kernel panic (visible only on the monitor, now
> also unresponsive).
Thanks for the report. I'll try to track it down.
If you could jot down the important bits of the panic message
(IP, Call-Trace) it would help me find the problem much quicker.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
snd-emu10k1 broken in 2.6.13
Hello. I am running FC4 and compiled a vanilla linux 2.6.13. After booting the kernel I see an error messages that says that it was unable to load snd-emu10k1 (see dmesg). In dmesg I got this: Sep 4 10:09:47 chello062178124144 kernel: snd_emu10k1: Unknown parameter `' Sep 4 10:09:47 chello062178124144 last message repeated 2 times the same modprobe.conf works in 2.6.12. I tryed to load it by hand (modprobe snd-emu10k1) => same result modprobe snd-emu10k1 index=0 => same result. I will attach my .config file (please CC me as I am not subscribed to the list) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.13 # Sun Sep 4 09:51:58 2005 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Processor type and features # CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # CONFIG_NUMA is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y CONFIG_HPET_TIMER=y CONFIG_X86_PM_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_GART_IOMMU=y CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_PHYSICAL_START=0x10 # CONFIG_KEXEC is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m # CONFIG_ACPI_HOTKEY is not set CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_ASUS=m CONFIG_ACPI_IBM=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=2001 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_ACPI_CONTAINER is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_POWERNOW_K8=y CONFIG_X86_POWERNOW_K8_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y CONFIG_X86_ACPI_CPUFREQ=m # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # CONFIG_X86_SPEEDSTEP_LIB is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_UNORDERED_IO is not set CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=m # CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY_PROC=y # CONFIG_PCI_NAMES is not set # CONFIG_PCI_DEBUG is not set # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=m # CONFIG_PCMCIA_LOAD_CIS is not set # CONFIG_PCMCIA_IOCTL is not set CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_PD6729=m CONFIG_I82092=m CONFIG_TCIC=m CONFIG_PCCARD_NONSTA
Re: kernel freezes with 2.6.12.5 and 2.6.13
On Mon, 29 Aug 2005, Chris Wright wrote: > * Peter Münster ([EMAIL PROTECTED]) wrote: > > On Mon, 29 Aug 2005, Chris Wright wrote: > > > > > * Peter Münster ([EMAIL PROTECTED]) wrote: > > > > with 2.6.12.4 no problem. But with a newer version, I get a black screen > > > > and no more network access, when trying to print (lpr some-file.ps). > > > > Everything else seems to work ok. > > > > Printer is a network-printer managed by cups. > > > > I suppose, it's a smp-problem, so here is my /proc/cpuinfo: > > > > > > Is this 100% reproducible? Do you get any kernel oops messages on > > > the console? There are very few patches between 2.6.12.4 and 2.6.12.5, > > > so if the problem is reproducible can you narrow to the specific patch? > > > > Yes, it's 100% reproducible. But I do not get any message. Display is > > shutting down, and no more access with ssh. Ctrl-Alt-Del does not work > > neither. Nothing in /var/log/messages. > > Are you running X? Can you reproduce running lpr from console command line? Friday I got some surprises: I could reproduce now the system crash (always with lpr and without X) with all other kernels too: 2.6.12.4, 2.6.12 and even with the kernel, that was really stable for a long time on my system: 2.6.11.3. So now, I believe, that there is a hardware problem. I'm sorry, having stolen your time... Greetings, Peter -- http://pmrb.free.fr/contact/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
Mark Fasheh <[EMAIL PROTECTED]> wrote: > > On Sun, Sep 04, 2005 at 12:23:43AM -0700, Andrew Morton wrote: > > > What would be an acceptable replacement? I admit that O_NONBLOCK -> > > > trylock > > > is a bit unfortunate, but really it just needs a bit to express that - > > > nobody over here cares what it's called. > > > > The whole idea of reinterpreting file operations to mean something utterly > > different just seems inappropriate to me. > Putting aside trylock for a minute, I'm not sure how utterly different the > operations are. You create a lock resource by creating a file named after > it. You get a lock (fd) at read or write level on the resource by calling > open(2) with the appropriate mode (O_RDONLY, O_WRONLY/O_RDWR). > Now that we've got an fd, lock value blocks are naturally represented as > file data which can be read(2) or written(2). > Close(2) drops the lock. > > A really trivial usage example from shell: > > node1$ echo "hello world" > mylock > node2$ cat mylock > hello world > > I could always give a more useful one after I get some sleep :) It isn't extensible though. One couldn't retain this approach while adding (random cfs ignorance exposure) upgrade-read, downgrade-write, query-for-various-runtime-stats, priority modification, whatever. > > You get a lot of goodies when using a filesystem - the ability for > > unrelated processes to look things up, resource release on exit(), etc. If > > those features are valuable in the ocfs2 context then fine. > Right, they certainly are and I think Joel, in another e-mail on this > thread, explained well the advantages of using a filesystem. > > > But I'd have thought that it would be saner and more extensible to add new > > syscalls (perhaps taking fd's) rather than overloading the open() mode in > > this manner. > The idea behind dlmfs was to very simply export a small set of cluster dlm > operations to userspace. Given that goal, I felt that a whole set of system > calls would have been overkill. That said, I think perhaps I should clarify > that I don't intend dlmfs to become _the_ userspace dlm api, just a simple > and (imho) intuitive one which could be trivially accessed from any software > which just knows how to read and write files. Well, as I say. Making it a filesystem is superficially attractive, but once you've build a super-dooper enterprise-grade infrastructure on top of it all, nobody's going to touch the fs interface by hand and you end up wondering why it's there, adding baggage. Not that I'm questioning the fs interface! It has useful permission management, monitoring and resource releasing characteristics. I'm questioning the open() tricks. I guess from Joel's tiny description, the filesystem's interpretation of mknod and mkdir look sensible enough. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: forbid to strace a program
Hi Andreas, On Sun, Sep 04, 2005 at 09:32:34AM +0200, Andreas Hartmann wrote: > > Can I ask why you want to hide the database password from root? > > It's easy: for security reasons. There could always be some bugs in some > software, which makes it possible for some other user, to gain root > privileges. Now, they could easily strace for information, they shouldn't > could do it. Then you're loosing your time. If the user gains root privileges, then he can do what he wants to get the password, including loading modules or scanning the memory. For instance, it happened to me several times that my browser crashed during a post with a very long message. Not funny at all. Then, as root, I started my hex editor and scaned all memory for words I was sure I wouldn't find anywhere else, and then I could restore my data by hand. Doing so to find a password is pretty easy too. And don't tell me that it's deleted very soon, because it's also possible to send lots of SIGSTOP/scan/SIGCONT very fast to try to catch the clear password. > The password they could see, isn't just used for the DB, but > for some other applications, too. That's the disadvantage of general > (single sign on) passwords. can't you use a specific password just for this app ? or use another server on which no user has access to relay your connections and insert the right password itself ? Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] Genesys USB 2.0 enclosures
On Sunday 04 September 2005 03:53, Alan Stern wrote: > > This one certainly goes into the Bizarro file. > > Just out of curiosity -- when you use the powered hub, does the drive work > even if you remove that delay completely? I haven't tested that. I will, next time I need the drive, which will probably be in about a week. I just wanted to make my backup, and finally managed to do that. I don't get it either what's really wrong with these chips - but it was one of the recommendations i found on the linux-usb device list pages. And it seems to work. If now only I can get the firewire part of one of them working without serialize_io, then I can use that too. Jan -- A billion here, a billion there -- pretty soon it adds up to real money. -- Sen. Everett Dirksen, on the U.S. defense budget - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: forbid to strace a program
On Sun, Sep 04, 2005 at 09:32:34AM +0200, Andreas Hartmann wrote: > Chase Venters wrote: > >> Is there another way to do this? If the password is crypted, I need a > >> passphrase or something other to decrypt it again. Not really a solution > >> of the problem. > >> > >> Therefore, it would be best, to hide it by preventing stracing of the > >> application to all users and root. > >> > >> Ok, root could search for the password directly in the memory, but this > >> would be not as easy as a strace. > > > > Obfuscation isn't really valid security. Making something 'harder' to break > > isn't a solution unless you're making it hard enough that current > > technology > > can't break it (eg... you always have the brute force option, but good > > crypto > > intends to make such an option impossible without expending zillions of > > clock > > cycles). > > You're right. If I would have a solution, which could do this, I would > prefer it. > > > > > Can I ask why you want to hide the database password from root? > > It's easy: for security reasons. There could always be some bugs in some > software, which makes it possible for some other user, to gain root > privileges. Now, they could easily strace for information, they shouldn't > could do it. The password they could see, isn't just used for the DB, but > for some other applications, too. That's the disadvantage of general > (single sign on) passwords. > I'm no security expert, but if root privileges are compromised, there's no way to plug anything. A kernel module can be loaded to do just about anything. Signals can be sent to obtain core dumps. Binaries can be switched. Network traffics can be sniffed. Kernel image can be replaced and rebooted while no one is watching without leaving any record. If security is important for your application, move the application into a separate machine in a physically protected place and use very restrictive firewall. Plugging strace() will make little (if any) change w.r.t. security. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
On Sun, Sep 04, 2005 at 01:18:05AM -0700, Andrew Morton wrote: > > I thought I stated this in my other email. We're not intending > > to extend dlmfs. > > Famous last words ;) Heh, of course :-) > I don't buy the general "fs is nice because we can script it" argument, > really. You can just write a few simple applications which provide access > to the syscalls (or the fs!) and then write scripts around those. I can't see how that works easily. I'm not worried about a tarball (eventually Red Hat and SuSE and Debian would have it). I'm thinking about this shell: exec 7http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Brand-new notebook useless with Linux...
Hi, On Sep 04 at 02:50:07, Matthew Garrett wrote: > Chuck Ebbert <[EMAIL PROTECTED]> wrote: > > > SMBus > > Is there anything on there that you actually want to talk to? Smart batteries are accesed thru the SMBus. If you want to know battery information, like the charge, you need to talk to the SMBus. There are some patches out there, not integrated yet into ACPI i think... regards, -- David Gómez Jabber ID: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
Joel Becker <[EMAIL PROTECTED]> wrote: > > I can't see how that works easily. I'm not worried about a > tarball (eventually Red Hat and SuSE and Debian would have it). I'm > thinking about this shell: > > exec 7 do stuff > exec 7 > If someone kills the shell while stuff is doing, the lock is unlocked > because fd 7 is closed. However, if you have an application to do the > locking: > > takelock domainxxx lock1 > do sutff > droplock domainxxx lock1 > > When someone kills the shell, the lock is leaked, becuase droplock isn't > called. And SEGV/QUIT/-9 (especially -9, folks love it too much) are > handled by the first example but not by the second. take-and-drop-lock -d domainxxx -l lock1 -e "do stuff" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
On Sun, Sep 04, 2005 at 02:18:36AM -0700, Andrew Morton wrote: > take-and-drop-lock -d domainxxx -l lock1 -e "do stuff" Ahh, but then you have to have lots of scripts somewhere in path, or do massive inline scripts. especially if you want to take another lock in there somewhere. It's doable, but it's nowhere near as easy. :-) Joel -- "I always thought the hardest questions were those I could not answer. Now I know they are the ones I can never ask." - Charlie Watkins Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: snd-emu10k1 broken in 2.6.13
Niko Nitsche wrote: dragoran wrote: Hello. I am running FC4 and compiled a vanilla linux 2.6.13. After booting the kernel I see an error messages that says that it was unable to load snd-emu10k1 (see dmesg). In dmesg I got this: Sep 4 10:09:47 chello062178124144 kernel: snd_emu10k1: Unknown parameter `' Sep 4 10:09:47 chello062178124144 last message repeated 2 times the same modprobe.conf works in 2.6.12. I tryed to load it by hand (modprobe snd-emu10k1) => same result modprobe snd-emu10k1 index=0 => same result. I will attach my .config file (please CC me as I am not subscribed to the list) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.13 # Sun Sep 4 09:51:58 2005 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Processor type and features # CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # CONFIG_NUMA is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y CONFIG_HPET_TIMER=y CONFIG_X86_PM_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_GART_IOMMU=y CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_PHYSICAL_START=0x10 # CONFIG_KEXEC is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m # CONFIG_ACPI_HOTKEY is not set CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_ASUS=m CONFIG_ACPI_IBM=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=2001 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_ACPI_CONTAINER is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_POWERNOW_K8=y CONFIG_X86_POWERNOW_K8_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y CONFIG_X86_ACPI_CPUFREQ=m # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # CONFIG_X86_SPEEDSTEP_LIB is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_UNORDERED_IO is not set CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=m # CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY_PROC=y # CONFIG_PCI_NAMES is not set # CONFIG_PCI_DEBUG is not set # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=m # CONFIG_PCMCIA_LOAD_CIS is not set # CONFIG_PCMCIA_IOCTL is not set CONFI
Re: [xfs-masters] [2.6 patch] fs/xfs/linux-2.6/xfs_buf.h: "extern inline" doesn't make sense
On Sat, Sep 03, 2005 at 03:23:47PM +0200, Adrian Bunk wrote: > "extern inline" doesn't make sense. Thanks, I put this in. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
8250_hp300: initialisation ordering bug
Hi, I've noticed that 8250_hp300 is buggy wrt the ordering of hardware initialisation to the visibility of devices to user space. Namely, 8250_hp300 does the following: line = serial8250_register_port(&port); ... /* Enable board-interrupts */ out_8(d->resource.start + DIO_VIRADDRBASE + DCA_IC, DCA_IC_IE); dio_set_drvdata(d, (void *)line); /* Reset the DCA */ out_8(d->resource.start + DIO_VIRADDRBASE + DCA_ID, 0xff); udelay(100); serial8250_register_port() makes the port visible to userspace, so from that point on it could be opened. However, if it's opened prior to the remainder of the above completing, we will be missing interrupts (and what effect does "reset the DCA" have?) Surely this hardware fiddling should be completed before we register the port? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-mm1
On Thu, Sep 01, 2005 at 03:55:42AM -0700 Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/ > I got: <7>Dead loop on netdevice eth0, fix it urgently! When using netconsole and printing out some information from kernel to console. The box uses: [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ :00:0f.0 Ethernet controller: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) Relevant config: CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set CONFIG_TULIP=y CONFIG_TULIP_MWI=y # CONFIG_TULIP_MMIO is not set CONFIG_TULIP_NAPI=y Matt, on another box I got some irq off hangs that went away when removing netconsole from the .config on a box with 3c59x. Is this known? The problem is getting backtraces when netconsole is active, but the last thing I see before the box goes is that some carrier is up... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Fix compilation in locomo.c
On Tue, Jul 26, 2005 at 08:30:43AM +0200, Pavel Machek wrote: > Do not access children in struct device directly, use > device_for_each_child helper instead. It fixes compilation. > > Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> Given up waiting for John/Richard to okay this, applied anyway. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: snd-emu10k1 broken in 2.6.13
dragoran wrote: Niko Nitsche wrote: dragoran wrote: Hello. I am running FC4 and compiled a vanilla linux 2.6.13. After booting the kernel I see an error messages that says that it was unable to load snd-emu10k1 (see dmesg). In dmesg I got this: Sep 4 10:09:47 chello062178124144 kernel: snd_emu10k1: Unknown parameter `' Sep 4 10:09:47 chello062178124144 last message repeated 2 times the same modprobe.conf works in 2.6.12. I tryed to load it by hand (modprobe snd-emu10k1) => same result modprobe snd-emu10k1 index=0 => same result. I will attach my .config file (please CC me as I am not subscribed to the list) Hi, I had the same problem with FC4/vanilla 2.6.13 and snd-intel8x0 and I had two lines in modprobe.conf like this: options snd-card-0 index=0 options snd-intel8x0 index=0 I removed them and now everything works just fine. Accutally I had the Unknown parameter `' messages before but the module loaded. sorry but this isn't solution (it works thought) but this happens for all modules that have a options line in /etc/modprobe.conf Is this a bug or has the syntax of modprobe.conf changed in 2.6.13? Well, those options lines are just wrong so I am not at all surprised that it failed. It should be: options snd-card-0 snd-intel8x0 options snd-intel8x0 index=0 So, dragoran, what options lines do you have? 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: Brand-new notebook useless with Linux...
On Sat, Sep 03, 2005 at 06:58:00PM -0400, Chuck Ebbert wrote: > I just bought a new notebook. Here is the output from lspci using the latest > pci.ids file from sourceforge: I'd suggest researching before buying. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: snd-emu10k1 broken in 2.6.13
James Courtier-Dutton wrote:
dragoran wrote:
Niko Nitsche wrote:
dragoran wrote:
Hello.
I am running FC4 and compiled a vanilla linux 2.6.13.
After booting the kernel I see an error messages that says that it was
unable to load snd-emu10k1 (see dmesg).
In dmesg I got this:
Sep 4 10:09:47 chello062178124144 kernel: snd_emu10k1: Unknown
parameter `'
Sep 4 10:09:47 chello062178124144 last message repeated 2 times
the same modprobe.conf works in 2.6.12.
I tryed to load it by hand (modprobe snd-emu10k1) => same result
modprobe snd-emu10k1 index=0 => same result.
I will attach my .config file
(please CC me as I am not subscribed to the list)
Hi,
I had the same problem with FC4/vanilla 2.6.13 and snd-intel8x0
and I had two lines in modprobe.conf like this:
options snd-card-0 index=0
options snd-intel8x0 index=0
I removed them and now everything works just fine. Accutally I had the
Unknown parameter `' messages before but the module loaded.
sorry but this isn't solution (it works thought) but this happens for
all modules that have a options line in /etc/modprobe.conf
Is this a bug or has the syntax of modprobe.conf changed in 2.6.13?
Well, those options lines are just wrong so I am not at all surprised
that it failed.
It should be:
options snd-card-0 snd-intel8x0
options snd-intel8x0 index=0
So, dragoran, what options lines do you have?
James
this is my modprobe.conf:
alias eth0 forcedeth
alias eth1 r8169
alias scsi_hostadapter sata_nv
alias snd-card-0 snd-emu10k1
options snd-card-0 index=0
options snd-emu10k1 index=0
remove snd-emu10k1 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-emu10k1
alias usb-controller ehci-hcd
alias usb-controller1 ohci-hcd
alias ieee1394-controller ohci1394
alias char-major-81 saa7134
options nvidia NVreg_EnableAGPFW=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/
Re: [patch] Add suspend/resume support to locomo.c
On Thu, Jul 21, 2005 at 07:25:58AM +0200, Pavel Machek wrote: > From: John Lenz <[EMAIL PROTECTED]> > > This adds low-level suspend/resume support to locomo.c. > > Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> Shouldn't this be signed off by John himself? Not applied. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: nfs4 client bug
Bret Towe <[EMAIL PROTECTED]> : [...] > after moving some files on the server to a new location then trying to > add the files > to xmms playlist i found the following in dmesg after xmms froze > wonder how many more items i can find... The system includes some binary only stuff. Please contact your vendor or provide the traces for a configuration wherein the relevant module was not loaded after boot. It may make sense to get in touch with [EMAIL PROTECTED] then. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Brand-new notebook useless with Linux...
> 05:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] > 802.11g Wireless LAN Controller (rev 02) Give 'ndiswrapper' a try. Works pretty well for me. Folkert van Heusden -- Try MultiTail! Multiple windows with logfiles, filtered with regular expressions, colored output, etc. etc. www.vanheusden.com/multitail/ -- Get your PGP/GPG key signed at www.biglumber.com! -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com signature.asc Description: Digital signature
Re: [uml-devel] Re: [patch 1/3] uml: share page bits handling between 2 and 3 level pagetables
On Friday 02 September 2005 22:17, Jeff Dike wrote:
> On Wed, Aug 10, 2005 at 09:37:28PM +0200, Blaisorblade wrote:
> > Also look, on the "set_pte" theme, at the attached patch.
> + WARN_ON(!pte_young(*pte) || pte_write(*pte) && !pte_dirty(*pte));
> This one has been firing on me, and I decided to figure out why. The
> culprit is this code in do_no_page:
> if (pte_none(*page_table)) {
> if (!PageReserved(new_page))
> inc_mm_counter(mm, rss);
>
> flush_icache_page(vma, new_page);
> entry = mk_pte(new_page, vma->vm_page_prot);
> if (write_access)
> entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> set_pte_at(mm, address, page_table, entry);
>
> The first mk_pte immediately sets the pte to the protection limits of
> the VMA, regardless of the access type.
> So, if it's a read access on
> a writeable page, we get a writeable, but not dirty pte, since the
> mkdirty never happens. The exercises the warning you added.
Thanks for noticing - I had really this doubt when writing some code (in the
patch, I've added a dirty PTEs on read accesses because I was unsure, and
even because of my warning).
> This seems somewhat bogus to me. If we set the pte protection to its
> limits, then the maybe_mkwrite is unneccesary.
> This doesn't seem to harm our dirty bit emulation. fix_range_common
> checks the dirty and accessed bits and disables read and write
> protection as appropriate.
> So, it seems like the warning could be dropped, or perhaps made more
> selective, like checking for is_write == 0 and VM_WRITE, but then the
> test is getting complicated.
No, just replace pte_write() with is_write, as below. They might not coincide,
but if on a write fault we return with a clean PTE, we'll loop indefinitely
(experienced while hacking on remap_f_p), so the warning above is definitely
correct.
WARN_ON(!pte_young(*pte) || is_write && !pte_dirty(*pte));
> Heff
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___
Yahoo! Messenger: chiamate gratuite in tutto il mondo
http://it.beta.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] lib/sort.c: small cleanups
On Saturday 03 September 2005 15:25, Adrian Bunk wrote: > This patch contains the following small cleanups: > - make two needlessly global functions static > - every file should #include the header files containing the prototypes > of it's global functions While this is a nice cleanup, does anybody remember, why the inner loops are duplicated in the source? If there are no arguments for it, I would like to consolidate them to a function or a define, if they share to much state. Or is the duplicate just considered cleaner? Regards Ingo Oeser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13 SMP on Athlon X2: nanosleep returning waay to soon, clock_gettime(CLOCK_REALTIME...) proceeding too fast
After replacing the kernel on a fresh FC4 install with a stock 2.6.13
(using gcc 3.2) and my own config it appears that the clock is going too
fast: it gains at least an hour every 12 hours or so. FC4 kernel (rpm:
kernel-2.6.11-1.1369_FC4) seems ok
I tried the following from another system with reliable clock:
for i in `yes|head -100`
do
/usr/bin/time -f %e rsh system_with_buggy_clock sleep 1
done | cat -n
annotated output:
1 1.03
2 1.03
3 1.03
4 1.03
5 1.03
6 1.03
7 1.02
8 1.03
9 1.03
10 1.03
11 1.03
12 1.03
13 1.03
14 1.03
15 1.03
16 0.72<==
17 1.03
18 1.03
19 1.03
20 1.03
21 1.03
22 1.03
23 1.03
24 1.02
25 1.03
26 1.03
27 1.03
28 1.03
29 1.03
30 1.03
31 1.03
32 1.03
33 1.03
34 0.14<==
35 1.03
36 1.03
37 1.03
38 1.03
39 1.03
40 1.03
41 1.03
42 1.02
43 1.03
44 1.03
45 1.03
46 1.03
47 1.03
48 1.03
49 1.03
50 1.03
51 1.03
52 0.18<==
53 1.03
54 1.03
55 1.03
56 1.03
57 1.03
58 1.03
59 1.03
60 1.02
61 1.03
62 1.03
63 1.03
64 1.04
65 1.03
66 1.03
67 1.03
68 1.03
69 1.03
70 0.13<==
71 1.03
72 1.03
73 1.03
74 1.03
75 1.03
76 1.03
77 1.03
78 1.02
79 1.03
80 1.03
81 1.03
82 1.03
83 1.03
84 1.03
85 1.03
86 1.03
87 1.03
88 0.15<==
89 1.03
90 1.03
91 1.03
92 1.03
93 1.03
94 1.03
95 1.03
96 1.02
97 1.03
98 1.03
99 1.03
100 1.03
I also ran the following script on the system with the unstable clock,
measuring timer interrupts per CPU as visible in /proc/interrupts:
CPU0 CPU1
0:67417075860969IO-APIC-edge timer
1: 45 10IO-APIC-edge i8042
2: 0 0 XT-PIC cascade
8: 0 1IO-APIC-edge rtc
14: 807745 907612IO-APIC-edge ide0
15: 834978 871118IO-APIC-edge ide1
17: 45336986 45939432 IO-APIC-level SysKonnect SK-98xx
18: 0 0 IO-APIC-level libata
21: 0 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5
22: 0 0 IO-APIC-level VIA8237
NMI: 0 0
LOC: 12601494 12601519
ERR: 0
MIS: 0
script:
#!/bin/sh
for i in `yes|head -100`
do
s1=`cat /proc/interrupts`
sleep 1
s2=`cat /proc/interrupts`
t10=`echo "$s1" | awk '$1=="0:"{ print $2}'`
t11=`echo "$s1" | awk '$1=="0:"{ print $3}'`
t20=`echo "$s2" | awk '$1=="0:"{ print $2}'`
t21=`echo "$s2" | awk '$1=="0:"{ print $3}'`
d1=`expr $t20 - $t10`
d2=`expr $t21 - $t11`
echo $d1 + $d2 = `expr $d1 + $d2`
done | cat -n
annotated output:
CPU0 CPU1 Total
---
1 0 + 251 = 251
2 0 + 251 = 251
3 0 + 251 = 251
4 0 + 251 = 251
5 0 + 251 = 251
6 52 + 196 = 248 <== (?)
7 251 + 0 = 251
8 251 + 0 = 251
9 251 + 0 = 251
10 251 + 0 = 251
11 251 + 0 = 251
12 251 + 0 = 251
13 251 + 0 = 251
14 251 + 0 = 251
15 251 + 0 = 251
16 147 + 1 = 148 <==
17 0 + 252 = 252
18 0 + 251 = 251
19 0 + 251 = 251
20 0 + 251 = 251
21 0 + 251 = 251
22 0 + 252 = 252
23 0 + 251 = 251
24 72 + 177 = 249 <== (?)
25 252 + 0 = 252
26 252 + 0 = 252
27 252 + 0 = 252
28 252 + 0 = 252
29 252 + 0 = 252
30 252 + 0 = 252
31 252 + 0 = 252
32 253 + 0 = 253
33 253 + 0 = 253
34 118 + 2 = 120 <==
35 0 + 253 = 253
36 0 + 253 = 253
37 0 + 253 = 253
38 0 + 253 = 253
39 0 + 252 = 252
40 0 + 252 = 252
41 0 + 252 = 252
42 78 + 171 = 249 <== (?)
43 252 + 0 = 252
44 252 + 0 = 252
45 252 + 0 = 252
46 252 + 0 = 252
47 251 + 0 = 251
48 251 + 0 = 251
49 251 + 0 = 251
50 251 + 0 = 251
51 251 + 0 = 251
52 121 + 1 = 122 <==
53 0 + 251 = 251
54 0 + 251 = 251
55 0 + 251 = 251
56 0 + 251 = 251
57 0 + 251 = 251
58 0 + 251 = 251
59 0 + 251 = 251
60 69 + 179 = 248 <== (?)
61 251 + 0 = 251
62 251 + 0 = 251
63 251 + 0 = 251
64 251 + 0 = 251
65 251 + 0 = 251
66 251 + 0 = 251
67 251 + 0 = 251
68 251 + 0 = 251
69 251 + 0 = 251
70 130 + 1 = 131 <
Re: [Linux-ATM-General] [ATMSAR] Request for review - update #1
Giampaolo Tomassoni <[EMAIL PROTECTED]> :
[...]
> However, I'm still hearing for your comments about the usefulness of an
> ATMSAR layer.
Afaik all but one pci ADSL modems are out of tree drivers and include various
level of proprietary code. If Duncan is not interested in changing its code,
the usefulness remains to be proven.
The codingstyle is broken. Please read again Documentation/CodingStyle,
remove the redundant typedef and the silly comments ("Reserve header space",
Encode packet into cells", ...).
- &page[strlen(page)] in atmProcRead sucks.
- "return" is not a function.
- consider 'goto' to handle the errors instead of deep nesting
- +const atmsar_aalops_t opsAALR = {
+ ATM_AAL0,
+ "raw",
-> use .foo = baz instead.
drivers/net/*c may give some hint.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: i386: kill !4KSTACKS
2005/9/4, Lee Revell <[EMAIL PROTECTED]>: > On Fri, 2005-09-02 at 02:39 +0200, Adrian Bunk wrote: > > 4Kb kernel stacks are the future on i386, and it seems the problems it > > initially caused are now sorted out. > > > > Does anyone knows about any currently unsolved problems? > > ndiswrapper Just a thought : why couldn't ndiswrapper set apart some piece of memory and use it as the stack by changing the esp register before executing windows code. Like http://article.gmane.org/gmane.linux.drivers.ndiswrapper.general/4737 It's dirty, I know, but after all they are executing win32 code ... Why wouldn't this work ? -- Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] fat: Remove duplicate directory scanning code
Hi!
This patch removes duplicate directory scanning code from fs/fat/dir.c. The
two functions that share identical code are fat_readdirx() and
fat_search_long(). This patch also renames fat_readdirx to __fat_readdir().
Tested on User-mode Linux with a small 16 MB vfat partition.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
dir.c | 239 +++---
1 file changed, 113 insertions(+), 126 deletions(-)
Index: 2.6/fs/fat/dir.c
===
--- 2.6.orig/fs/fat/dir.c
+++ 2.6/fs/fat/dir.c
@@ -197,6 +197,95 @@ fat_shortname2uni(struct nls_table *nls,
return len;
}
+enum {
+ DIRENT_END = 0x01,
+ NOT_EXTENDED= 0x02,
+ DIR_END = 0x03
+};
+
+/**
+ * fat_parse_extended - Parse extended directory entry.
+ *
+ * This function returns zero on success, negative value on error, or one of
+ * the following:
+ *
+ * %DIRENT_END - Directory entry ended unexpectedly.
+ * %NOT_EXTENDED - Directory entry does not contain extended attributes.
+ * %DIR_END - Directory has no more entries.
+ */
+static int fat_parse_extended(struct inode *dir,
+ loff_t *pos,
+ struct buffer_head **bh,
+ struct msdos_dir_entry **de,
+ wchar_t **unicode,
+ unsigned char *nr_slots)
+{
+ struct msdos_dir_slot *ds;
+ unsigned char id;
+ unsigned char slot;
+ unsigned char slots;
+ unsigned char sum;
+ unsigned char alias_checksum;
+ int i;
+
+ if (!*unicode) {
+ *unicode = (wchar_t *) __get_free_page(GFP_KERNEL);
+ if (!*unicode) {
+ brelse(*bh);
+ return -ENOMEM;
+ }
+ }
+parse_long:
+ slots = 0;
+ ds = (struct msdos_dir_slot *) *de;
+ id = ds->id;
+ if (!(id & 0x40))
+ return DIRENT_END;
+ slots = id & ~0x40;
+ if (slots > 20 || !slots) /* ceil(256 * 2 / 26) */
+ return DIRENT_END;
+ *nr_slots = slots;
+ alias_checksum = ds->alias_checksum;
+
+ slot = slots;
+ while (1) {
+ int offset;
+
+ slot--;
+ offset = slot * 13;
+ fat16_towchar(*unicode + offset, ds->name0_4, 5);
+ fat16_towchar(*unicode + offset + 5, ds->name5_10, 6);
+ fat16_towchar(*unicode + offset + 11, ds->name11_12, 2);
+
+ if (ds->id & 0x40) {
+ (*unicode)[offset + 13] = 0;
+ }
+ if (fat_get_entry(dir, pos, bh, de) < 0)
+ return DIR_END;
+ if (slot == 0)
+ break;
+ ds = (struct msdos_dir_slot *) *de;
+ if (ds->attr != ATTR_EXT)
+ return NOT_EXTENDED;
+ if ((ds->id & ~0x40) != slot)
+ goto parse_long;
+ if (ds->alias_checksum != alias_checksum)
+ goto parse_long;
+ }
+ if ((*de)->name[0] == DELETED_FLAG)
+ return DIRENT_END;
+ if ((*de)->attr == ATTR_EXT)
+ goto parse_long;
+ if (IS_FREE((*de)->name) || ((*de)->attr & ATTR_VOLUME))
+ return DIRENT_END;
+ for (sum = 0, i = 0; i < 11; i++)
+ sum = (((sum&1)<<7)|((sum&0xfe)>>1)) + (*de)->name[i];
+ if (sum != alias_checksum)
+ *nr_slots = 0;
+
+ return 0;
+}
+
/*
* Return values: negative -> error, 0 -> not found, positive -> found,
* value is the total amount of slots, including the shortname entry.
@@ -234,68 +323,16 @@ parse_record:
if (de->attr != ATTR_EXT && IS_FREE(de->name))
continue;
if (de->attr == ATTR_EXT) {
- struct msdos_dir_slot *ds;
- unsigned char id;
- unsigned char slot;
- unsigned char slots;
- unsigned char sum;
- unsigned char alias_checksum;
-
- if (!unicode) {
- unicode = (wchar_t *)
- __get_free_page(GFP_KERNEL);
- if (!unicode) {
- brelse(bh);
- return -ENOMEM;
- }
- }
-parse_long:
- slots = 0;
- ds = (struct msdos_dir_slot *) de;
- id = ds->id;
- if (!(id & 0x40))
- continue;
- slots = id & ~0x40;
- if (slots > 20 || !slots) /* ceil(256 * 2 / 26) */
+
Re: snd-emu10k1 broken in 2.6.13
>> Well, those options lines are just wrong so I am not at all surprised
>> that it failed.
>>
>> It should be:
>> options snd-card-0 snd-intel8x0
>> options snd-intel8x0 index=0
>>
>> So, dragoran, what options lines do you have?
>>
>> James
>>
>>
Thanks James!
but I think those are the correct ones:
alias snd-card-0 snd-intel8x0
options snd-intel8x0 "index=0"
options snd-card-0 "index=0"
> this is my modprobe.conf:
> alias eth0 forcedeth
> alias eth1 r8169
> alias scsi_hostadapter sata_nv
> alias snd-card-0 snd-emu10k1
> options snd-card-0 index=0
> options snd-emu10k1 index=0
> remove snd-emu10k1 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ;
> }; /sbin/modprobe -r --ignore-remove snd-emu10k1
> alias usb-controller ehci-hcd
> alias usb-controller1 ohci-hcd
> alias ieee1394-controller ohci1394
> alias char-major-81 saa7134
> options nvidia NVreg_EnableAGPFW=1
>
so at least for me, using double quotes for options works out
Niko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: snd-emu10k1 broken in 2.6.13
>> Well, those options lines are just wrong so I am not at all surprised
>> that it failed.
>>
>> It should be:
>> options snd-card-0 snd-intel8x0
>> options snd-intel8x0 index=0
>>
>> So, dragoran, what options lines do you have?
>>
>> James
>>
>>
Thanks James!
but I think those are the correct ones:
alias snd-card-0 snd-intel8x0
options snd-intel8x0 "index=0"
> this is my modprobe.conf:
> alias eth0 forcedeth
> alias eth1 r8169
> alias scsi_hostadapter sata_nv
> alias snd-card-0 snd-emu10k1
> options snd-card-0 index=0
> options snd-emu10k1 index=0
> remove snd-emu10k1 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ;
> }; /sbin/modprobe -r --ignore-remove snd-emu10k1
> alias usb-controller ehci-hcd
> alias usb-controller1 ohci-hcd
> alias ieee1394-controller ohci1394
> alias char-major-81 saa7134
> options nvidia NVreg_EnableAGPFW=1
>
so at least for me, using double quotes for options works out
Niko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[CFT] forcedeth backport to 2.4
Hi,
Attached is a backport of the latest forcedeth version to 2.4. It
includes lots of changes, among them:
- a critical bugfix for nv_open(): ifdown/ifup cycles resulted in an
incomplete initialization that causes hangs after a few MB network traffic.
- jumbo frame support
- far better ethtool support
- 64-bit dma support
- support for additional nforce versions.
It compiles and boots, but I can't test it properly. Could you give it a
try?
--
Manfred
--- 2.4/drivers/net/forcedeth.c 2005-01-19 15:09:56.0 +0100
+++ build-2.4/drivers/net/forcedeth.c 2005-09-04 13:58:07.0 +0200
@@ -79,6 +79,22 @@
* 0.30: 25 Sep 2004: rx checksum support for nf 250 Gb. Add rx reset
*into nv_close, otherwise reenabling for wol can
*cause DMA to kfree'd memory.
+ * 0.31: 14 Nov 2004: ethtool support for getting/setting link
+ *capabilities.
+ * 0.32: 16 Apr 2005: RX_ERROR4 handling added.
+ * 0.33: 16 May 2005: Support for MCP51 added.
+ * 0.34: 18 Jun 2005: Add DEV_NEED_LINKTIMER to all nForce nics.
+ * 0.35: 26 Jun 2005: Support for MCP55 added.
+ * 0.36: 28 Jun 2005: Add jumbo frame support.
+ * 0.37: 10 Jul 2005: Additional ethtool support, cleanup of pci id list
+ * 0.38: 16 Jul 2005: tx irq rewrite: Use global flags instead of
+ *per-packet flags.
+ * 0.39: 18 Jul 2005: Add 64bit descriptor support.
+ * 0.40: 19 Jul 2005: Add support for mac address change.
+ * 0.41: 30 Jul 2005: Write back original MAC in nv_close instead
+ *of nv_remove
+ * 0.42: 06 Aug 2005: Fix lack of link speed initialization
+ *in the second (and later) nv_open call
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -90,7 +106,7 @@
* DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
* superfluous timer interrupts from the nic.
*/
-#define FORCEDETH_VERSION "0.30"
+#define FORCEDETH_VERSION "0.42"
#define DRV_NAME "forcedeth"
#include
@@ -108,6 +124,7 @@
#include
#include
#include
+#include
#include
#include
@@ -125,11 +142,10 @@
* Hardware access:
*/
-#define DEV_NEED_LASTPACKET1 0x0001 /* set LASTPACKET1 in tx flags */
-#define DEV_IRQMASK_1 0x0002 /* use NVREG_IRQMASK_WANTED_1 for irq
mask */
-#define DEV_IRQMASK_2 0x0004 /* use NVREG_IRQMASK_WANTED_2 for irq
mask */
-#define DEV_NEED_TIMERIRQ 0x0008 /* set the timer irq flag in the irq
mask */
-#define DEV_NEED_LINKTIMER 0x0010 /* poll link settings. Relies on the
timer irq */
+#define DEV_NEED_TIMERIRQ 0x0001 /* set the timer irq flag in the irq
mask */
+#define DEV_NEED_LINKTIMER 0x0002 /* poll link settings. Relies on the
timer irq */
+#define DEV_HAS_LARGEDESC 0x0004 /* device supports jumbo frames and
needs packet format 2 */
+#define DEV_HAS_HIGH_DMA 0x0008 /* device supports 64bit dma */
enum {
NvRegIrqStatus = 0x000,
@@ -140,13 +156,16 @@
#define NVREG_IRQ_RX 0x0002
#define NVREG_IRQ_RX_NOBUF 0x0004
#define NVREG_IRQ_TX_ERR 0x0008
-#define NVREG_IRQ_TX2 0x0010
+#define NVREG_IRQ_TX_OK0x0010
#define NVREG_IRQ_TIMER0x0020
#define NVREG_IRQ_LINK 0x0040
+#define NVREG_IRQ_TX_ERROR 0x0080
#define NVREG_IRQ_TX1 0x0100
-#define NVREG_IRQMASK_WANTED_1 0x005f
-#define NVREG_IRQMASK_WANTED_2 0x0147
-#define NVREG_IRQ_UNKNOWN
(~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1))
+#define NVREG_IRQMASK_WANTED 0x00df
+
+#define NVREG_IRQ_UNKNOWN
(~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR| \
+
NVREG_IRQ_TX_OK|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX_ERROR| \
+ NVREG_IRQ_TX1))
NvRegUnknownSetupReg6 = 0x008,
#define NVREG_UNKSETUP6_VAL3
@@ -211,6 +230,7 @@
#define NVREG_LINKSPEED_10 1000
#define NVREG_LINKSPEED_100100
#define NVREG_LINKSPEED_1000 50
+#define NVREG_LINKSPEED_MASK (0xFFF)
NvRegUnknownSetupReg5 = 0x130,
#define NVREG_UNKSETUP5_BIT31 (1<<31)
NvRegUnknownSetupReg3 = 0x13c,
@@ -279,6 +299,18 @@
u32 FlagLen;
};
+struct ring_desc_ex {
+ u32 PacketBufferHigh;
+ u32 PacketBufferLow;
+ u32 Reserved;
+ u32 FlagLen;
+};
+
+typedef union _ring_type {
+ struct ring_desc* orig;
+ struct ring_desc_ex* ex;
+} ring_type;
+
#define FLAG_MASK_V1 0x
#define FLAG_MASK_V2 0xc000
#define LEN_MASK_V1 (0x ^ FLAG_MASK_V1)
@@ -286,7 +318,7 @@
#define NV_TX
Re: Brand-new notebook useless with Linux...
On 02:50 Sun 04 Sep , Matthew Garrett wrote:
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > Audio ("unknown codec")
>
> snd-ati-atiixp ought to drive it - if it doesn't, that's probably a bug.
>
> > Modem ("no codec available")
>
> It's a winmodem. What were you expecting?
snd-atiixp-modem should drive this too.
Sasha.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: i386: kill !4KSTACKS
On Friday 02 September 2005 09:08, Alex Davis wrote: > ndiswrapper and driverloader will not work reliably with 4k stacks. > This is because of the Windoze drivers they use, to which, obviously, > they do not have the source. Since quite a few laptops have built-in > wireless cards by companies who will not release an open-source driver, > or won't release specs, ndiswrapper and driverloader are the only way > to get these cards to work. > Please don't tell me to "get a linux-supported wireless card". I don't > want the clutter of an external wireless adapter sticking out of my laptop, > nor do I want to spend money on a card when I have a free and working > solution. Please don't tell me to "care for closed-source drivers". I don't want the pain of debugging crashes on the machines which run unknown code in kernel space. IOW, if you run closed source modules - it's _your_ problem, not ours. -- 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: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Sunday 04 September 2005 12:12, Harald Welte wrote: > cmx_llseek just use return nonseekable_open(inode, filp); as your last statement in cmx_open() instead of return 0; to really disable any file pointer positioning (e.g. pwrite/pread too). Addtionally cmx_llseek() is implement already as "no_llseek()" by the VFS, so you delete it from the driver an use no_llseek() from the VFS instead. Regards Ingo Oeser pgpfDmvKLYTKl.pgp Description: PGP signature
R: [Linux-ATM-General] [ATMSAR] Request for review - update #1
> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] conto di
> Francois Romieu
> Inviato: domenica 4 settembre 2005 14.01
> A: Giampaolo Tomassoni
> Cc: linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]
> Oggetto: Re: [Linux-ATM-General] [ATMSAR] Request for review - update #1
>
>
> Giampaolo Tomassoni <[EMAIL PROTECTED]> :
> [...]
> > However, I'm still hearing for your comments about the usefulness of an
> > ATMSAR layer.
>
> Afaik all but one pci ADSL modems are out of tree drivers and
> include various
> level of proprietary code. If Duncan is not interested in
> changing its code,
> the usefulness remains to be proven.
Well, the idea is that more pci devices may appear, as adsl-enabled embedded
systems will begin to appear in the market.
Also, I believe that adsl will carry much more services then just AAL5 for
internet connection in the future. Even if the ATMSAR actually lacks of AAL1
and AAL2/3 capabilities, adding them in a single, specialized module is much
easier than swimming in a usb+atm middle layer.
Finally, the fact that ATMSAR is device-unspecific makes it easier to maintain,
I guess.
> The codingstyle is broken. Please read again Documentation/CodingStyle,
That's a matter of taste: even Linus burned the GNU coding style book...
However, if it is needed by the linux community, I shurely will fix it whenever
the ATMSAR idea will get passed: I'm just gathering feedbacks like the previous
one you expressed.
> remove the redundant typedef
Oh, you mean the "typedef enum _HECSTS ..." ?
You're right, thanks.
> and the silly comments ("Reserve
> header space",
> Encode packet into cells", ...).
I would prefer to explain better what the ATMSAR is doing there. So, I'll get
your as a "clarify silly comments". Ok?
> - &page[strlen(page)] in atmProcRead sucks.
Why? It is preceded by an strcpy(page,...). A constant would be worse if
someone changes the prefix string...
Or is a page (a pointer) + strlen(page) (an integer) preferred over a closed
syntax?
> - "return" is not a function.
Not even for() or while(). But doesn't they look cute this way?
> - consider 'goto' to handle the errors instead of deep nesting
I prefer not using goto when not required to. Nesting is far more readable to
my opinion. Compilers do work fine with both.
Anyway, which are the functions you are objecting?
> - +const atmsar_aalops_t opsAALR = {
> + ATM_AAL0,
> + "raw",
> -> use .foo = baz instead.
atmasr_aalops_t is not an exported structure (you'll find just an opaque
definition in include/linux/atmsar.h), so it is not meant to be statically
declared by device drivers. But I guess that the problem is readability, right?
Ok, I'm going to consider your hint in the next patch version.
> drivers/net/*c may give some hint.
>
> --
> Ueimor
Thank you for your help.
May I ask if this is just your own contribution or if you are in charge of
something in the linux and/or linux-atm projects?
Regards,
---
Giampaolo Tomassoni - IT Consultant
Piazza VIII Aprile 1948, 4
I-53044 Chiusi (SI) - Italy
Ph: +39-0578-21100
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: i386: kill !4KSTACKS
Adrian Bunk wrote (ao): > 4Kb kernel stacks are the future on i386, and it seems the problems it > initially caused are now sorted out. > > Does anyone knows about any currently unsolved problems? > > I'd like to: > - get a patch into on of the next -mm kernels that unconditionally > enables 4KSTACKS > - if there won't be new reports of breakages, send a patch to > completely remove !4KSTACKS for 2.6.15 > > In -mm, Reiser4 still has a dependency on !4KSTACKS. > I've mentioned this at least twice to the Reiser4 people, and they > should check why this dependency is still there and if there are still > stack issues in Reiser4 fix them. > > If not people using Reiser4 on i386 will have to decide whether to > switch the filesystem or the architecture... FWIW: I use Reiser4 for several months now on several i386 systems, and I always remove the "&& !4STACKS" from fs/reiser4/Kconfig and enable CONFIG_4KSTACKS: # zgrep -E 'REISER4|4KSTACKS' /proc/config.gz CONFIG_REISER4_FS=y # CONFIG_REISER4_DEBUG is not set CONFIG_4KSTACKS=y Also using lvm2, or raid1, or raid5, on ATA, SATA or SCSI. I haven't experienced any problems yet, but the systems don't see heavy usage too. Kind regards, Sander -- Humilis IT Services and Solutions http://www.humilis.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: [PATCH] quiet non-x86 option ROM warnings
On Tue, Feb 15, Jesse Barnes wrote:
> Both the r128 and radeon drivers complain if they don't find an x86 option
> ROM
> on the device they're talking to. This would be fine, except that the
> message is incorrect--not all option ROMs are required to be x86 based. This
> small patch just removes the messages altogether, causing the drivers to
> *silently* fall back to the non-x86 option ROM behavior (it works fine and
> there's no cause for alarm).
This patch wasnt applied, back in February this year. Please do so now.
Quiet an incorrect warning in aty128fb and radeonfb about the PCI ROM
content. Macs work just find without that signature.
Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
drivers/video/aty/aty128fb.c|2 +-
drivers/video/aty/radeon_base.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.13-fb-rom/drivers/video/aty/aty128fb.c
===
--- linux-2.6.13-fb-rom.orig/drivers/video/aty/aty128fb.c
+++ linux-2.6.13-fb-rom/drivers/video/aty/aty128fb.c
@@ -806,7 +806,7 @@ static void __iomem * __init aty128_map_
/* Very simple test to make sure it appeared */
if (BIOS_IN16(0) != 0xaa55) {
- printk(KERN_ERR "aty128fb: Invalid ROM signature %x should be
0xaa55\n",
+ printk(KERN_DEBUG "aty128fb: Invalid ROM signature %x should be
0xaa55\n",
BIOS_IN16(0));
goto failed;
}
Index: linux-2.6.13-fb-rom/drivers/video/aty/radeon_base.c
===
--- linux-2.6.13-fb-rom.orig/drivers/video/aty/radeon_base.c
+++ linux-2.6.13-fb-rom/drivers/video/aty/radeon_base.c
@@ -329,7 +329,7 @@ static int __devinit radeon_map_ROM(stru
/* Very simple test to make sure it appeared */
if (BIOS_IN16(0) != 0xaa55) {
- printk(KERN_ERR "radeonfb (%s): Invalid ROM signature %x should
be"
+ printk(KERN_DEBUG "radeonfb (%s): Invalid ROM signature %x
should be"
"0xaa55\n", pci_name(rinfo->pdev), BIOS_IN16(0));
goto failed;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: i386: kill !4KSTACKS
On Sunday 04 September 2005 08:49, Denis Vlasenko wrote: > On Friday 02 September 2005 09:08, Alex Davis wrote: > > ndiswrapper and driverloader will not work reliably with 4k stacks. > > This is because of the Windoze drivers they use, to which, obviously, > > they do not have the source. Since quite a few laptops have built-in > > wireless cards by companies who will not release an open-source driver, > > or won't release specs, ndiswrapper and driverloader are the only way > > to get these cards to work. > > Please don't tell me to "get a linux-supported wireless card". I don't > > want the clutter of an external wireless adapter sticking out of my laptop, > > nor do I want to spend money on a card when I have a free and working > > solution. > > Please don't tell me to "care for closed-source drivers". I don't > want the pain of debugging crashes on the machines which run unknown code > in kernel space. > > IOW, if you run closed source modules - it's _your_ problem, not ours. > -- There is no logic to the above statement. We know when a kernel is tainted and do not try hard to debug problems when tainted . We also know that ndiswrapper and friends _currently_ let people use hardware that otherwise would have to run MS stuff. We know that 4K stacks hurt the above. Do we really want to break working configs just to enforce 4K stacks? How does it hurt to make 4K the default and allow 8K? What _might_ make sense is to make 8K a reason to taint the kernel. 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/
[PATCH] vm: swap prefetch-1
Thanks to those who tested the swap prefetch code in its first public
iteration. Here is a respin of the code which improves its behaviour to be
virtually unnoticable, and fix a couple of bugs that showed up.
Changes:
This version is suspend aware
Swap prefetches are limited to SWAP_CLUSTER_MAX (=128kb) per second
Prefetching is delayed whenever memory watermark limits are missed, or swap is
going in or out. The delay has been reduced to 5 seconds though.
Memory pressure while in the actual prefetch code will break out of it
The dependence on an new timer interface was abolished
Other cleanups and tweaks
Please test and report back. Assuming no bugs show up in this version, it will
be included in the next -ck.
The latest patch is available for download from here:
http://ck.kolivas.org/patches/swap-prefetch/
and is attached to this email
Cheers,
Con
This patch implements swap prefetching when the vm is in an idle state.
Add a list of pages that are added to swap. Then use that list when the vm is
idle, as determined by not failing any watermark tests or swapping in/out
pages, to prefetch pages in the most recently used order back into swap cache
with a low priority kernel thread.
Leaving the pages on swap and in swap cache means that if any vm stress is
encountered without using those prefetched pages, the swap cache entries can
be dropped and they are already in swap without needing to be rewritten out.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
include/linux/fs.h |2
include/linux/swap.h | 27 +
init/Kconfig | 11 ++
mm/Makefile |1
mm/page_alloc.c | 10 +
mm/swap.c|3
mm/swap_prefetch.c | 260 +++
mm/swap_state.c | 12 ++
mm/vmscan.c |1
9 files changed, 324 insertions(+), 3 deletions(-)
Index: linux-2.6.13-sp/include/linux/fs.h
===
--- linux-2.6.13-sp.orig/include/linux/fs.h 2005-09-04 23:53:39.0 +1000
+++ linux-2.6.13-sp/include/linux/fs.h 2005-09-04 23:54:04.0 +1000
@@ -340,6 +340,8 @@ struct address_space {
struct inode *host; /* owner: inode, block_device */
struct radix_tree_root page_tree; /* radix tree of all pages */
rwlock_t tree_lock; /* and rwlock protecting it */
+ struct radix_tree_root swap_tree; /* radix tree of swapped pages */
+ struct list_head swapped_pages; /* list of swapped pages */
unsigned int i_mmap_writable;/* count VM_SHARED mappings */
struct prio_tree_root i_mmap; /* tree of private and shared mappings */
struct list_head i_mmap_nonlinear;/*list VM_NONLINEAR mappings */
Index: linux-2.6.13-sp/include/linux/swap.h
===
--- linux-2.6.13-sp.orig/include/linux/swap.h 2005-09-04 23:53:39.0 +1000
+++ linux-2.6.13-sp/include/linux/swap.h 2005-09-04 23:54:04.0 +1000
@@ -206,6 +206,7 @@ extern void free_pages_and_swap_cache(st
extern struct page * lookup_swap_cache(swp_entry_t);
extern struct page * read_swap_cache_async(swp_entry_t, struct vm_area_struct *vma,
unsigned long addr);
+extern int add_to_swap_cache(struct page *page, swp_entry_t entry);
/* linux/mm/swapfile.c */
extern long total_swap_pages;
extern unsigned int nr_swapfiles;
@@ -247,6 +248,32 @@ static inline void put_swap_token(struct
__put_swap_token(mm);
}
+#ifdef CONFIG_SWAP_PREFETCH
+/* mm/swap_prefetch.c */
+extern void prepare_prefetch(void);
+extern void add_to_swapped_list(unsigned long index);
+extern void remove_from_swapped_list(unsigned long index);
+extern void delay_prefetch(void);
+
+#else /* CONFIG_SWAP_PREFETCH */
+static inline void add_to_swapped_list(unsigned long index)
+{
+}
+
+static inline void prepare_prefetch(void)
+{
+}
+
+static inline void remove_from_swapped_list(unsigned long index)
+{
+}
+
+static inline void delay_prefetch(void)
+{
+}
+
+#endif /* CONFIG_SWAP_PREFETCH */
+
#else /* CONFIG_SWAP */
#define total_swap_pages 0
Index: linux-2.6.13-sp/init/Kconfig
===
--- linux-2.6.13-sp.orig/init/Kconfig 2005-09-04 23:53:39.0 +1000
+++ linux-2.6.13-sp/init/Kconfig 2005-09-04 23:54:04.0 +1000
@@ -87,6 +87,17 @@ config SWAP
used to provide more virtual memory than the actual RAM present
in your computer. If unsure say Y.
+config SWAP_PREFETCH
+ bool "Support for prefetching swapped memory (EXPERIMENTAL)"
+ depends on SWAP && EXPERIMENTAL
+ default n
+ ---help---
+ This option will allow the kernel to prefetch swapped memory pages
+ when idle. The pages will be kept on both swap and in swap_cache
+ thus avoiding the need for further I/O if either ram or swap space
+ is required. This is desirable on workstations.
+ Desktop users will most likely want to say Y.
+
config SYSVIPC
bool "System V IPC"
depends on MMU
Index: linux-2.6.13-sp/mm/Makefile
Re: [PATCH] quiet non-x86 option ROM warnings
Olaf Hering <[EMAIL PROTECTED]> writes: > - printk(KERN_ERR "radeonfb (%s): Invalid ROM signature %x should > be" > + printk(KERN_DEBUG "radeonfb (%s): Invalid ROM signature %x > should be" > "0xaa55\n", pci_name(rinfo->pdev), BIOS_IN16(0)); While you are at it you could also add the missing space. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13 SMP on Athlon X2: nanosleep returning waay to soon, clock_gettime(CLOCK_REALTIME...) proceeding too fast
On Sun, Sep 04, 2005 at 01:39:15PM +0200, Frank van Maarseveen wrote: > After replacing the kernel on a fresh FC4 install with a stock 2.6.13 > (using gcc 3.2) and my own config it appears that the clock is going too > fast: it gains at least an hour every 12 hours or so. FC4 kernel (rpm: > kernel-2.6.11-1.1369_FC4) seems ok Mind sticking this information in bugzilla.kernel.org, bug 5105? > annotated output: > > CPU0 CPU1 Total > --- > 1 0 + 251 = 251 > 2 0 + 251 = 251 > 3 0 + 251 = 251 > 4 0 + 251 = 251 > 5 0 + 251 = 251 > 6 52 + 196 = 248<== (?) > 7 251 + 0 = 251 > 8 251 + 0 = 251 > 9 251 + 0 = 251 > 10 251 + 0 = 251 > 11 251 + 0 = 251 > 12 251 + 0 = 251 > 13 251 + 0 = 251 > 14 251 + 0 = 251 > 15 251 + 0 = 251 > 16 147 + 1 = 148 <== > 17 0 + 252 = 252 Hmm, very interesting. -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Brand-new notebook useless with Linux...
On Sun, Sep 04, 2005 at 11:10:12AM +0200, David Gómez wrote: > Smart batteries are accesed thru the SMBus. If you want to know > battery information, like the charge, you need to talk to the SMBus. Smart batteries are i2c devices, but you talk to them via the embedded controller rather than via the system SMBus. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1: PCMCIA problem
Hi! > > > One more piece of information. This is the one that loops: > > > > > > echo 30 > /sys/class/firmware/timeout > > > > Try echo -n ... > > Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch. > Obviously if you write 30\n and the write returns 2 then the shell will > then try to write the \n. That returns zero and the shell tries again, ad > infinitum. Can you revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch, instead? Kernel should not provide "nice" interface. Striping trailing whitespace is wrong, just teach users to use sysfs right. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
>Please don't tell me to "care for closed-source drivers". ndiswrapper is NOT closed source. And I'm not asking you to "care". >I don't want the pain of debugging crashes on the machines which run unknown >code >in kernel space. I'm not asking you to debug crashes. I'm simply requesting that the kernel stack size situation remain as it is: with 8K as the default and 4K configurable. >vda I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Brand-new notebook useless with Linux...
for my V2311US with Broadcom 4318 these drivers worked with ndiswrapper: ftp://ftp.support.acer-euro.com/notebook/ferrari_4000/driver/winxp64bit/80211g.zip while these did not: http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM94318 PCIID: 14e4:4318 the ati-drivers 8.16.20 worked very well with the xpress 200 (ATI IXP) in it at 1280x768 (proprietary drivers seem to be a problem with software-suspend, which might be why i have not successfully resumed yet, vbetools to help here does not compile for me..yet?) the twice as fast clock problem you will find several times on kernel.org's bugzilla for now add "noapic" to the kernel parameters, this works here at least till it is fixed (i havent tried booting 2.6.13 w/o it to be honest) i get the charge of my battery, no info on current use through /proc/acpi/battery have not really tried using mmc slot i hope this helps you anything Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: empty patch-2.6.13-git? patches on ftp.kernel.org
David Woodhouse wrote: > On Fri, 2005-09-02 at 02:00 -0700, Linus Torvalds wrote: > >>Ahh. Please change that to >> >>rm -rf tmp-empty-tree >>mkdir tmp-empty-tree >>cd tmp-empty-tree >>git-init-db >> >>because otherwise you'll almost certainly hit something else later >>on.. > > > OK, done. > -git4 is again empty patch-2.6.13-git4.bz2 03-Sep-2005 02:03 14 [ ] patch-2.6.13-git4.bz2.sign 03-Sep-2005 02:03 248 [ ] patch-2.6.13-git4.gz 03-Sep-2005 02:03 20 [ ] patch-2.6.13-git4.gz.sign 03-Sep-2005 02:03 248 [ ] patch-2.6.13-git4.id 03-Sep-2005 02:01 41 [ ] patch-2.6.13-git4.log 03-Sep-2005 02:03 526K [ ] patch-2.6.13-git4.sign 03-Sep-2005 02:03 248 -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1
Giampaolo Tomassoni <[EMAIL PROTECTED]> :
[...]
> Well, the idea is that more pci devices may appear, as adsl-enabled
> embedded systems will begin to appear in the market.
>
> Also, I believe that adsl will carry much more services then just AAL5 for
> internet connection in the future.
I'd be happily surprized to see more documented ADSL PCI/USB device in the
near future. :o(
> Even if the ATMSAR actually lacks of AAL1 and AAL2/3 capabilities, adding
> them in a single, specialized module is much easier than swimming in a
> usb+atm middle layer.
>
> Finally, the fact that ATMSAR is device-unspecific makes it easier to
> maintain, I guess.
Ok. Your suggestion may have more impact if there is a patch to convert
the sole existing in-kernel driver to use this module.
[...]
> > The codingstyle is broken. Please read again Documentation/CodingStyle,
>
> That's a matter of taste: even Linus burned the GNU coding style book...
An uniform codingstyle is useful when people need to review code. Something
is wrong when a reviewer must uncipher a piece of code. You will find areas
in the kernel whose trends differ but a codingstyle from Mars is usually a
hint. So it is not _only_ a matter of taste.
> However, if it is needed by the linux community, I shurely will fix it
> whenever the ATMSAR idea will get passed: I'm just gathering feedbacks
> like the previous one you expressed.
You may have more feedback/review then. I only gave a cursory look at the
code.
[...]
> > remove the redundant typedef
>
> Oh, you mean the "typedef enum _HECSTS ..." ?
Rather the "typedef struct atmsar_dev atmsar_dev_t;" (yes, I know the "It
saves typing" argument). Maybe something could be done at the same time
regarding the need for the forward declarations.
[...]
> > and the silly comments ("Reserve
> > header space",
> > Encode packet into cells", ...).
>
> I would prefer to explain better what the ATMSAR is doing there. So, I'll
> get your as a "clarify silly comments". Ok?
s/what/why/
And no, documenting a call to skb_reserve is silly.
[...]
> > - &page[strlen(page)] in atmProcRead sucks.
>
> Why? It is preceded by an strcpy(page,...). A constant would be worse if
> someone changes the prefix string...
The value returned by sprintf and friends contains the needed offset, i.e.
buf += sprintf(buf, ...);.
[...]
> > - "return" is not a function.
>
> Not even for() or while(). But doesn't they look cute this way?
No.
for (), while (), return rc;
[...]
> > - consider 'goto' to handle the errors instead of deep nesting
>
> I prefer not using goto when not required to. Nesting is far more readable
> to my opinion.
OTOH, it makes ugly code to have it fit in a 80 columns console.
[...]
> Anyway, which are the functions you are objecting?
atmSend. Probably others.
If you can make the code look like existing in-kernel code (not fs/cifs
please) say network or ata driver code and you do not need goto, it's fine
too.
[...]
> > - +const atmsar_aalops_t opsAALR = {
> > + ATM_AAL0,
> > + "raw",
> > -> use .foo = baz instead.
>
> atmasr_aalops_t is not an exported structure (you'll find just an opaque
> definition in include/linux/atmsar.h), so it is not meant to be statically
> declared by device drivers. But I guess that the problem is readability,
> right?
struct foo zoy {
.bar= barbar,
.baz= bazbaz,
.quuz = ...
};
[...]
> May I ask if this is just your own contribution or if you are in charge of
> something in the linux and/or linux-atm projects?
/me scratches head
http://ww.google.com/search?hl=en&q=romieu+linux+cabal
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-floppy - software eject not working with LS-120 drive
Denis Vlasenko wrote:
On Friday 02 September 2005 23:47, Ondrej Zary wrote:
Hello,
I've bought "new" LS-120 drive and found that software eject does not
work with 2.6.13 kernel:
[EMAIL PROTECTED]:~# eject /dev/hdc
eject: unable to eject, last error: Invalid argument
The drive spins up and after a while the command fails.
This appears in dmesg after each eject attempt:
hdc: unknown partition table
ide-floppy: hdc: I/O error, pc = 1b, key = 5, asc = 24, ascq = 0
When I boot 2.4.31, eject works fine.
Can you probive something narrower than 2.4.31 -> 2.6.13 jump?
The problem is caused by idefloppy_ioctl() function which *first* tries
generic_ide_ioctl() and *only* if it fails with -EINVAL, proceeds with
the specific ioctls.
This patch fixes it by first going through the internal ioctls and only
trying generic_ide_ioctl() if none of them matches.
Signed-off-by: Ondrej Zary <[EMAIL PROTECTED]>
--
Ondrej Zary
--- linux-2.6.13-orig/drivers/ide/ide-floppy.c 2005-08-29 01:41:01.0
+0200
+++ linux-2.6.13-pentium/drivers/ide/ide-floppy.c 2005-09-04
14:07:53.0 +0200
@@ -2038,11 +2038,9 @@
struct ide_floppy_obj *floppy = ide_floppy_g(bdev->bd_disk);
ide_drive_t *drive = floppy->drive;
void __user *argp = (void __user *)arg;
- int err = generic_ide_ioctl(drive, file, bdev, cmd, arg);
+ int err;
int prevent = (arg) ? 1 : 0;
idefloppy_pc_t pc;
- if (err != -EINVAL)
- return err;
switch (cmd) {
case CDROMEJECT:
@@ -2094,7 +2092,7 @@
case IDEFLOPPY_IOCTL_FORMAT_GET_PROGRESS:
return idefloppy_get_format_progress(drive, argp);
}
- return -EINVAL;
+ return generic_ide_ioctl(drive, file, bdev, cmd, arg);
}
static int idefloppy_media_changed(struct gendisk *disk)
Re: empty patch-2.6.13-git? patches on ftp.kernel.org
On Sun, 2005-09-04 at 17:31 +0200, Jan Dittmer wrote: > David Woodhouse wrote: > > On Fri, 2005-09-02 at 02:00 -0700, Linus Torvalds wrote: > > > >>Ahh. Please change that to > >> > >>rm -rf tmp-empty-tree > >>mkdir tmp-empty-tree > >>cd tmp-empty-tree > >>git-init-db > >> > >>because otherwise you'll almost certainly hit something else later > >>on.. > > > > > > OK, done. > > > > -git4 is again empty Hm, yes. + rm -rf tmp-empty-tree + mkdir tmp-empty-tree + cd tmp-empty-tree + git-init-db /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/branches/: Permission denied + unset GIT_DIR + git-read-tree f505380ba7b98ec97bf25300c2a58aeae903530b fatal: unable to create new cachefile Fixed now; thanks. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Brand-new notebook useless with Linux...
In-Reply-To: <[EMAIL PROTECTED]> On Sun, 4 Sep 2005 at 02:50:07 +0100, Matthew Garrett wrote: > > Additionally, the system clock runs at 2x normal speed with PowerNow > > enabled. > > http://bugzilla.kernel.org/show_bug.cgi?id=3927 Well that's the most bizarre tale of timer interrupt routing I've seen to date. Has Maciej seen this? (cc'd) I have these messages: ACPI: PM-Timer IO Port: 0x8008 Using pmtmr for high-res timesource Calibrating delay using timer specific routine.. 3205.65 BogoMIPS (lpj=6411312) .TIMER: vector=0x31 pin1=2 pin2=-1 and: ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) __ Chuck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ATMSAR] Request for review - update #1
On Sunday 04 September 2005 12:05, Giampaolo Tomassoni wrote: > Dears, > > thanks to Jiri Slaby who found a bug in the AAL0 handling of the ATMSAR > module. > > I attach a fixed version of the atmsar patch as a diff against the 2.6.13 > kernel tree. > [snip] Just out of curiosity, is there ANY reason why this has to be done in the kernel? The PPPoATM module for pppd implements (via linux-atm) a completely userspace ATM decoder.. if anything, now redundant ATM stack code should be REMOVED from Linux! Most distributions (to my knowledge) supporting the speedtouch modem do so using the method prescribed on speedtouch.sf.net; an entirely userspace procedure. pppd does all the ATM magic. Does this have real-world applications beyond the Speedtouch DSL modems? If not, I propose adding this code to linux-atm, not the kernel, since most users of USB speedtouch DSL modems will not be using the kernel's ATM. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-mm1: hangs during boot ...
On Sun, 2005-09-04 at 01:24 +1200, Reuben Farrelly wrote:
> I am seeing it fill up my messages log as it is logging 1 or so messages each
> minute. I've emailed the SCSI maintainer James Bottomley twice about it but
> had no response either time.
OK, can you try this ... it should confirm the theory if the messages go
away.
Thanks,
James
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -315,7 +315,7 @@ int scsi_execute(struct scsi_device *sde
req->sense = sense;
req->sense_len = 0;
req->timeout = timeout;
- req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL;
+ req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL | REQ_QUIET;
/*
* head injection *required* here otherwise quiesce won't work
@@ -927,17 +927,20 @@ void scsi_io_completion(struct scsi_cmnd
scsi_requeue_command(q, cmd);
return;
}
- printk(KERN_INFO "Device %s not ready.\n",
- req->rq_disk ? req->rq_disk->disk_name : "");
+ if (!(req->flags & REQ_QUIET))
+ dev_printk(KERN_INFO,
+ &cmd->device->sdev_gendev,
+ "Device not ready.\n");
cmd = scsi_end_request(cmd, 0, this_count, 1);
return;
case VOLUME_OVERFLOW:
- printk(KERN_INFO "Volume overflow <%d %d %d %d> CDB: ",
- cmd->device->host->host_no,
- (int)cmd->device->channel,
- (int)cmd->device->id, (int)cmd->device->lun);
- __scsi_print_command(cmd->data_cmnd);
- scsi_print_sense("", cmd);
+ if (!(req->flags & REQ_QUIET)) {
+ dev_printk(KERN_INFO,
+ &cmd->device->sdev_gendev,
+ "Volume overflow, CDB: ");
+ __scsi_print_command(cmd->data_cmnd);
+ scsi_print_sense("", cmd);
+ }
cmd = scsi_end_request(cmd, 0, block_bytes, 1);
return;
default:
@@ -954,15 +957,13 @@ void scsi_io_completion(struct scsi_cmnd
return;
}
if (result) {
- if (!(req->flags & REQ_SPECIAL))
- printk(KERN_INFO "SCSI error : <%d %d %d %d> return
code "
- "= 0x%x\n", cmd->device->host->host_no,
- cmd->device->channel,
- cmd->device->id,
- cmd->device->lun, result);
+ if (!(req->flags & REQ_QUIET)) {
+ dev_printk(KERN_INFO, &cmd->device->sdev_gendev,
+ "SCSI error: return code = 0x%x\n", result);
- if (driver_byte(result) & DRIVER_SENSE)
- scsi_print_sense("", cmd);
+ if (driver_byte(result) & DRIVER_SENSE)
+ scsi_print_sense("", cmd);
+ }
/*
* Mark a single buffer as not uptodate. Queue the remainder.
* We sometimes get this cruft in the event that a medium error
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Potential IPSec DoS/Kernel Panic with 2.6.13
> -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-kernel- > [EMAIL PROTECTED] On Behalf Of Herbert Xu > Sent: Sunday, September 04, 2005 4:24 AM > To: Matt LaPlante > Cc: linux-kernel@vger.kernel.org > Subject: Re: Potential IPSec DoS/Kernel Panic with 2.6.13 > > Matt LaPlante <[EMAIL PROTECTED]> wrote: > > > > network connectivity on my router. Upon further inspection I noticed > the > > packet had actually caused a kernel panic (visible only on the monitor, > now > > also unresponsive). > > Thanks for the report. I'll try to track it down. > > If you could jot down the important bits of the panic message > (IP, Call-Trace) it would help me find the problem much quicker. I'd be more than happy to help you track this one down. The problem here is that the panic scrolls up and off the screen after which the system is unusable. Is there a way for me to capture it or redirect it somewhere that I can read it? I can also include my kernel config or any other system details of interest. Thanks. - Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ATMSAR] Request for review - update #1
On Sun, 4 Sep 2005, Alistair John Strachan wrote: On Sunday 04 September 2005 12:05, Giampaolo Tomassoni wrote: Dears, thanks to Jiri Slaby who found a bug in the AAL0 handling of the ATMSAR module. I attach a fixed version of the atmsar patch as a diff against the 2.6.13 kernel tree. [snip] Just out of curiosity, is there ANY reason why this has to be done in the kernel? The PPPoATM module for pppd implements (via linux-atm) a completely userspace ATM decoder.. if anything, now redundant ATM stack code should be REMOVED from Linux! Most distributions (to my knowledge) supporting the speedtouch modem do so using the method prescribed on speedtouch.sf.net; an entirely userspace procedure. pppd does all the ATM magic. Does this have real-world applications beyond the Speedtouch DSL modems? If not, I propose adding this code to linux-atm, not the kernel, since most users of USB speedtouch DSL modems will not be using the kernel's ATM. I am using SpeedTouch 330 modem with kernel driver (on Gentoo). The instalation is currently (with firmware loader instead of modem_run) very simple: USE="atm" emerge ppp, download firmware and place it in /lib/firmware, compile the kernel with speedtch support. I tried to use userspace driver some time ago but it wasn't working for me so I gave up. I was using modem_run with kernel driver for long time to load the firmware but there were many problems with it too (nearly every kernel or modem_run upgrade was breaking something, modem_run was hanging in D state in most unapropriate moments and so on). Now I am using pure kernel driver and firmware loader and it works 100% ok. There were no problems with it for long time. And I don't even want to look at this userspace driver again. Since Linux newer was (or is going to be) userspace-driver OS, maybe we should leave it that way... Grzegorz Kulewski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: i386: kill !4KSTACKS
On Sunday 04 September 2005 7:49 am, Denis Vlasenko wrote: > On Friday 02 September 2005 09:08, Alex Davis wrote: > > ndiswrapper and driverloader will not work reliably with 4k stacks. > > This is because of the Windoze drivers they use, to which, obviously, > > they do not have the source. Since quite a few laptops have built-in > > wireless cards by companies who will not release an open-source driver, > > or won't release specs, ndiswrapper and driverloader are the only way > > to get these cards to work. > > Please don't tell me to "get a linux-supported wireless card". I don't > > want the clutter of an external wireless adapter sticking out of my > > laptop, nor do I want to spend money on a card when I have a free and > > working solution. > > Please don't tell me to "care for closed-source drivers". I don't > want the pain of debugging crashes on the machines which run unknown code > in kernel space. > > IOW, if you run closed source modules - it's _your_ problem, not ours. > -- > vda > - No one is asking you to 'care' about our problems running a notebook with a closed source driver under ndiswrapper. We aren't asking you to debug problems with them either. All we're asking is for you to not go out of your way to break existing working machines, and make it difficult to run Linux on them. You are talking about knowingly removing an option that allows many machines to currently run without problems, some of them for reasons other than closed source code. If you want 4k stacks to be the default, I have no problem with that. If you want to rip out the provision for 8k stacks to be selectable at build time, that is a different issue entirely. Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ATMSAR] Request for review - update #1
Giampaolo Tomassoni napsal(a):
I attach a fixed version of the atmsar patch as a diff against the 2.6.13
kernel tree.
static inline void dump_skb (char * prefix, unsigned int vc, struct
sk_buff * skb) {
what's this? 81+ chars on line
{ on a newline, please
' * ' --> ' *'
spin_lock_irqsave (&txq->lock, flags);
indent is tab (tab is as long as 8 chars), no 3, 4, 5 or ... spaces
and many, many others, please read CodingStyle in Documentation.
thanks,
--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~ [EMAIL PROTECTED] ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ATMSAR] Request for review - update #1
On Sunday 04 September 2005 17:41, Grzegorz Kulewski wrote: > On Sun, 4 Sep 2005, Alistair John Strachan wrote: > > On Sunday 04 September 2005 12:05, Giampaolo Tomassoni wrote: > >> Dears, > >> > >> thanks to Jiri Slaby who found a bug in the AAL0 handling of the ATMSAR > >> module. > >> > >> I attach a fixed version of the atmsar patch as a diff against the > >> 2.6.13 kernel tree. > > > > [snip] > > > > Just out of curiosity, is there ANY reason why this has to be done in the > > kernel? The PPPoATM module for pppd implements (via linux-atm) a > > completely userspace ATM decoder.. if anything, now redundant ATM stack > > code should be REMOVED from Linux! > > > > Most distributions (to my knowledge) supporting the speedtouch modem do > > so using the method prescribed on speedtouch.sf.net; an entirely > > userspace procedure. pppd does all the ATM magic. > > > > Does this have real-world applications beyond the Speedtouch DSL modems? > > If not, I propose adding this code to linux-atm, not the kernel, since > > most users of USB speedtouch DSL modems will not be using the kernel's > > ATM. > > I am using SpeedTouch 330 modem with kernel driver (on Gentoo). > > The instalation is currently (with firmware loader instead of modem_run) > very simple: USE="atm" emerge ppp, download firmware and place it in > /lib/firmware, compile the kernel with speedtch support. Compared to "place the firmware in /lib/firmware" on many other distros, this sounds like a lot of work! The kernel speedtch provides no advantages to its userspace alternative. > I tried to use userspace driver some time ago but it wasn't working for me > so I gave up. I was using modem_run with kernel driver for long time to > load the firmware but there were many problems with it too (nearly every > kernel or modem_run upgrade was breaking something, modem_run was hanging > in D state in most unapropriate moments and so on). This is not the case any longer. > Now I am using pure kernel driver and firmware loader and it works 100% > ok. There were no problems with it for long time. And I don't even want to > look at this userspace driver again. Conversely people (including myself) found the kernel implementation to be buggy, and when userspace breaks, you can simply restart it.. when the kernel breaks, you have to reboot. > Since Linux newer was (or is going to be) userspace-driver OS, maybe we > should leave it that way... No. What can be done in userspace, within valid performance constraints, usually should be. This has always been the Linux kernel way. The speedtouch modem is a USB device, and there are many existing userspace "driver" implementations for USB devices. Including speedtouch. I'm not necessarily saying this code shouldn't be in the kernel, I'd just be interested to know why it has to be. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.6.13 breaks libpcap (and tcpdump).
Herbert Xu wrote: We aren't handling the reading of specific fields like the IP protocol field correctly. This patch should make it work again. I can't spot the problem, could you give me a hint? I tried to move this logic into the new load_pointer function but it all came out messy so I simply rolled it back. case BPF_LD|BPF_W|BPF_ABS: k = fentry->k; load_w: - ptr = load_pointer(skb, k, 4, &tmp); + if (k >= 0) + ptr = skb_header_pointer(skb, k, 4, &tmp); + else if (k < SKF_AD_OFF) + ptr = load_pointer(skb, k); + else + break; The old value of ptr will be used in this case, it should be explicitly set to NULL to abort. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: i386: kill !4KSTACKS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Davis wrote: >>Please don't tell me to "care for closed-source drivers". > > ndiswrapper is NOT closed source. And I'm not asking you to "care". While ndiswrapper might not be closed source, I would not call the windows driver it loads open source ... There is really no difference between madwifi+closed source hal to ndiswrapper+windows driver. Both are just as (non-)debuggable. Ok, madwifi exposes more of it's driver source to us, but still. // Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDGyrOBrn2kJu9P78RAvIxAJ426eTZbTtB5v92A+ipxsKEFW4sPACgnYna iXGFMduZgJ92UriSHvwTW3g= =YcU6 -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: RFC: i386: kill !4KSTACKS
On 9/4/05, Paul Misner <[EMAIL PROTECTED]> wrote: > No one is asking you to 'care' about our problems running a notebook with a > closed source driver under ndiswrapper. Yes you are. You're asking for 4KSTACKS config option to maintained and it is not something you get for free. Besides, if it is indeed ripped out of mainline kernel, you can always keep it a separate patch for ndiswrapper. Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: i386: kill !4KSTACKS
* Stefan Smietanowski ([EMAIL PROTECTED]) wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Alex Davis wrote: > >>Please don't tell me to "care for closed-source drivers". > > > > ndiswrapper is NOT closed source. And I'm not asking you to "care". > > While ndiswrapper might not be closed source, I would not call the > windows driver it loads open source ... Would it be possible for ndiswrapper to provide a seperate stack to the windows code so this problem is seperable? How debuggable is stack overrun? I mean if I am the unlucky admin who decides to setup a crypto/raid/stripe/thing setup which runs out of stack somewhere how easy will it be for someone who doesn't know the innards to know what happened as opposed to running into a random oops? Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex / \ _|_ http://www.treblig.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/
[patch] Bring the Vaio's RA826G HDA (82801) to life ...
Add the subsystem PCI devid to the list (on top of 2.6.13).
- Davide
Signed-off-by: Davide Libenzi
diff -Nru linux-2.6.13/sound/pci/hda/patch_realtek.c
linux-2.6.13.mod/sound/pci/hda/patch_realtek.c
--- linux-2.6.13/sound/pci/hda/patch_realtek.c 2005-09-03 15:59:25.0
-0700
+++ linux-2.6.13.mod/sound/pci/hda/patch_realtek.c 2005-09-03
15:33:14.0 -0700
@@ -1519,7 +1519,8 @@
/* Back 3 jack, front 2 jack (Internal add Aux-In) */
{ .pci_subvendor = 0x1025, .pci_subdevice = 0xe310, .config =
ALC880_3ST },
{ .pci_subvendor = 0x104d, .pci_subdevice = 0x81d6, .config = ALC880_3ST },
+ { .pci_subvendor = 0x104d, .pci_subdevice = 0x81a0, .config = ALC880_3ST },
/* Back 3 jack plus 1 SPDIF out jack, front 2 jack */
{ .modelname = "3stack-digout", .config = ALC880_3ST_DIG },
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: i386: kill !4KSTACKS
> Yes you are. You're asking for 4KSTACKS config option to maintained > and it is not something you get for free. Besides, if it is indeed > ripped out of mainline kernel, you can always keep it a separate patch > for ndiswrapper. Though 4K stacks are used a lot, they probably aren't used on all configurations yet. Other situations may arise where 8K stacks may be preferred. It is too early to kill 8K stacks imho. -- Bas Westerbaan http://blog.w-nz.com/ GPG Public Keys: http://w-nz.com/keys/bas.westerbaan.asc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ALSA, snd_intel8x0m and kexec() don't work together (2.6.13-rc3-git4 and 2.6.13-rc3-git3)
* Ralf Hildebrandt <[EMAIL PROTECTED]>: > * Ralf Hildebrandt <[EMAIL PROTECTED]>: > > > The one message strinking me as odd during the boot-process is: > > Jul 21 19:50:01 kasbah kernel: AC'97 warm reset still in progress? > > [0x] > > More details: If I unload the sounddriver: > > # rmmod snd_intel8x0 > > and the reload it: > > # modprobe snd_intel8x0 > > I get: > > ACPI: PCI Interrupt :00:06.0[A] -> Link [LACI] -> GSI 22 (level, low) -> > IRQ 19 > PCI: Setting latency timer of device :00:06.0 to 64 > AC'97 warm reset still in progress? [0x] > Intel ICH: probe of :00:06.0 failed with error -5 Fixed with 2.6.3-git3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ATMSAR] Request for review - update #1
On Sun, 4 Sep 2005, Alistair John Strachan wrote: On Sunday 04 September 2005 17:41, Grzegorz Kulewski wrote: On Sun, 4 Sep 2005, Alistair John Strachan wrote: On Sunday 04 September 2005 12:05, Giampaolo Tomassoni wrote: Dears, thanks to Jiri Slaby who found a bug in the AAL0 handling of the ATMSAR module. I attach a fixed version of the atmsar patch as a diff against the 2.6.13 kernel tree. [snip] Just out of curiosity, is there ANY reason why this has to be done in the kernel? The PPPoATM module for pppd implements (via linux-atm) a completely userspace ATM decoder.. if anything, now redundant ATM stack code should be REMOVED from Linux! Most distributions (to my knowledge) supporting the speedtouch modem do so using the method prescribed on speedtouch.sf.net; an entirely userspace procedure. pppd does all the ATM magic. Does this have real-world applications beyond the Speedtouch DSL modems? If not, I propose adding this code to linux-atm, not the kernel, since most users of USB speedtouch DSL modems will not be using the kernel's ATM. I am using SpeedTouch 330 modem with kernel driver (on Gentoo). The instalation is currently (with firmware loader instead of modem_run) very simple: USE="atm" emerge ppp, download firmware and place it in /lib/firmware, compile the kernel with speedtch support. Compared to "place the firmware in /lib/firmware" on many other distros, this sounds like a lot of work! The kernel speedtch provides no advantages to its userspace alternative. Are you saying that you do not need to install ppp and compile (or install binary) kernel on other distros??? I tried to use userspace driver some time ago but it wasn't working for me so I gave up. I was using modem_run with kernel driver for long time to load the firmware but there were many problems with it too (nearly every kernel or modem_run upgrade was breaking something, modem_run was hanging in D state in most unapropriate moments and so on). This is not the case any longer. Maybe. But there were many bugs in modem_run, usbfs, usb drivers in kernel, ACPI, IRQ routing and so on. They caused modem_run to hang or do something stupid without even telling user what is broken. In my experience when one bug was fixed other appeared in the next kernel. So even if now everything works ok you have no guarantee that next release won't break something... :) Now I am using pure kernel driver and firmware loader and it works 100% ok. There were no problems with it for long time. And I don't even want to look at this userspace driver again. Conversely people (including myself) found the kernel implementation to be buggy, and when userspace breaks, you can simply restart it.. when the kernel breaks, you have to reboot. 1. But you still use the kernel even with userspace driver. So it still can break forcing you to reboot. 2. I have no problems with kernel driver. All problems that I saw in the past were problems in other subsystems (usbfs, usb drivers, ACPI, IRQ, ...). 3. Restarting modem_run was never enought for me. I always at least had to unplug the modem from USB port. Or more often reboot. So I see no gain here. Since Linux newer was (or is going to be) userspace-driver OS, maybe we should leave it that way... No. What can be done in userspace, within valid performance constraints, usually should be. This has always been the Linux kernel way. But not device drivers. I do not think that Linux has good infrastructure for drivers in userspace (yes I know that there are some). Also are you sure that performance and latencies are ok with userspace driver even if system is under load? The speedtouch modem is a USB device, and there are many existing userspace "driver" implementations for USB devices. Including speedtouch. I'm not necessarily saying this code shouldn't be in the kernel, I'd just be interested to know why it has to be. Well, as you are saing it hasn't... :) But since it is there and works for me I am interested in not changing this state without really good reason. Grzegorz Kulewski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.6.13 breaks libpcap (and tcpdump).
Patrick McHardy wrote: Herbert Xu wrote: We aren't handling the reading of specific fields like the IP protocol field correctly. This patch should make it work again. I can't spot the problem, could you give me a hint? Never mind, I got it, we never fall through to the second switch statement anymore. I think we could simply break when load_pointer returns NULL. The switch statement will fall through to the default case and return 0 for all cases but 0 > k >= SKF_AD_OFF. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc coredump with 2.6.12+ kernels
Hello again, Got some more info that may be of value here. After I saw gcc coredump on me with 2.6.13 I tried halting my system and I saw a kernel panic while shutting down. The stack trace it showed me was: flush_tlb_mm+201 exit_mmap+249 mmput+49 do_exit+434 sys_reboot+264 __group_send_sig_info+184 group_send_info+118 thread_return thread_return+82 filp_close+110 system_call+126 All typed down by hand since it never made it into a log, so there can be omissions and typos in there (and I didn't feel like typing down all those 64-bit hex numbers, sorry). Johnny Stenback wrote: Alexander Nyberg wrote: On Sat, Sep 03, 2005 at 10:25:37AM -0700 Johnny Stenback wrote: Hey all, I just attempted to upgrade my kernel to 2.6.13. The kernel appears to boot and run just fine, but when I try to build any larger projects like Mozilla or the Linux kernel I constantly get segfaults from gcc. All other apps *seem* to work fine. I remember seeing this with 2.6.12 too when I tried to upgrade to it too but I didn't have the time to investigate at all then, but now I see the same problem with 2.6.13. The last version I've used that didn't show this problem is 2.6.11.3, and that's running with no problems here. When gcc segfaults I get the following messages in the messages log: cc1[16775]: segfault at rip 0036f2b0119e rsp 7faaf0a0 error 4 cc1[17086]: segfault at rip 0036f2b0119e rsp 7fc4dfc0 error 4 cc1[17788]: segfault at rip 0036f2b0119e rsp 7fd777e0 error 4 cc1[17823]: segfault at rip 0036f2b0119e rsp 7fc4d630 error 4 cc1[17895]: segfault at rip 0036f2b0119e rsp 7ffd2330 error 4 I'm on a dual AMD Opteron system, running x86_64 code. Using Fedora Core 2 (yeah, old, I know...) and gcc 3.3.3 20040412. Does it still happen if you run: echo 0 > /proc/sys/kernel/randomize_va_space Just tried that, and I still get the same error, and the same error in the log too (just a different address): cc1plus[2961]: segfault at rip 0036f2b0119e rsp 7fffdbb0 error 4 Anything else I can try? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- jst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: i386: kill !4KSTACKS
Guillaume Chazarain wrote: Just a thought : why couldn't ndiswrapper set apart some piece of memory and use it as the stack by changing the esp register before executing windows code. Like http://article.gmane.org/gmane.linux.drivers.ndiswrapper.general/4737 It's dirty, I know, but after all they are executing win32 code ... Why wouldn't this work ? I think this would be a good idea. I don't see any reason in principle why the ndiswrapper code couldn't use a separate stack for the Win32 driver code. Sharing the stack between the Linux kernel and whatever junk is going on inside the Windows driver seems rather inherently fragile.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
>takelock domainxxx lock1 >do sutff >droplock domainxxx lock1 > > When someone kills the shell, the lock is leaked, becuase droplock isn't > called. Why not open the lock resource (or the lock space) instead of individual locks as file? It then looks like this: open lock space file takelock lockresource lock1 do stuff droplock lockresource lock1 close lock space file Then if you are killed the ->release of lock space file should take care of cleaning up all the locks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
R: [ATMSAR] Request for review - update #1
> -Messaggio originale- > Da: Alistair John Strachan [mailto:[EMAIL PROTECTED] > Inviato: domenica 4 settembre 2005 18.21 > > ...omissis... > > Just out of curiosity, is there ANY reason why this has to be done in the > kernel? The PPPoATM module for pppd implements (via linux-atm) a > completely > userspace ATM decoder.. if anything, now redundant ATM stack code > should be > REMOVED from Linux! This may be true for AAL5 support, which is the way by which data is actually transferred between ADSL DSLAMs and CPE equipment. This may not be generally true, however: most providers are already delivering internet+voice solutions over ADSL channels (here in Italy, in example, Telecom offers Alice Mia, which is an ADSL line with internet access and VoIP for added voice capabilities). Albeit the voice part of these solutions are actually based on VoIP technology, it is not the best way to do this. In the future, I believe we will easily see internet + voice sols based over AAL5 + AAL2/3, or even multi voice channels over AAL2/3 over ADSL (replacing ISDN PRIs and multi-BRIs -based lines for PABX connection). When (and if) that will happen, we will probabily need a kernel-based solution since cell timing and QoS is a much stricter requirement with non-AAL5 encodings, such that it is easier to attain from inside the kernel than from userland. So, I'm not that shure all the ATM code is to be stripped out of the kernel. Maybe it can be done with the PPPoATM network interface. But probably it can't be done with the ATM core and the ATM SAR code. Wherever the latter will be in ATMUSB, in ATMSAR or in a device driver. The PPPoATM module is a network interface. It stays on the other side of the ATM world: [netif] <-> [PPPoATM] <-> [atmif] <-> [ATM] <-> [ATMSAR] <-> [device driver]. I'm not a PPPoATM expert, but it may probably be possible to have all the PPPoATM code in userland. But the [ATM] <-> [ATMSAR] <-> [device driver] chain is probably too close to hardware to gain any benefit by "userlanding" it. > > ...omissis... > > > -- > Cheers, > Alistair. Cheers, giampaolo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
R: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1
> -Messaggio originale-
> Da: Francois Romieu [mailto:[EMAIL PROTECTED]
> Inviato: domenica 4 settembre 2005 17.33
> A: Giampaolo Tomassoni
> Cc: linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]
> Oggetto: Re: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1
>
> ...omissis...
>
> I'd be happily surprized to see more documented ADSL PCI/USB device in the
> near future. :o(
OT Question. What about an open adsl device? The linux community had been
bumped out by the adsl market for at least a couple of years, and nobody knows
(or tells) why...
That could be a definitive answer. Is there anybody interested in this?
>
> ...omissis...
>
> > Finally, the fact that ATMSAR is device-unspecific makes it easier to
> > maintain, I guess.
>
> Ok. Your suggestion may have more impact if there is a patch to convert
> the sole existing in-kernel driver to use this module.
Mmmh. I can try to do this, but I would prefer to hear Sands about this.
>
> ...omissis
>
> An uniform codingstyle is useful when people need to review code.
> Something is wrong when a reviewer must uncipher a piece of code.
> You will find areas in the kernel whose trends differ but a codingstyle
> from Mars is usually a hint. So it is not _only_ a matter of taste.
Ok, ok. I'll (try to) behave...
>
> ...omissis...
>
> You may have more feedback/review then. I only gave a cursory look at the
> code.
Right, that's what I'm looking for.
>
> ...omissis...
>
> Rather the "typedef struct atmsar_dev atmsar_dev_t;" (yes, I know the "It
> saves typing" argument). Maybe something could be done at the same time
> regarding the need for the forward declarations.
Well, fine. I'll "struct _whatever *". But atmsar_dev_t no, that nonono: it
mimics the atm_dev_t typedef... It's all around the idea a developer needs to
use atmsar_dev_t instead of atm_dev_t...
>
> ...omissis...
>
> s/what/why/
>
> And no, documenting a call to skb_reserve is silly.
...
>
> ...omissis...
>
> The value returned by sprintf and friends contains the needed offset, i.e.
> buf += sprintf(buf, ...);.
I used an strcpy() to put the constant string in the buffer. However, I'm
changing it this way:
if(skip-- == 0) {
count = strlen(strcpy(page, "dnrate:\t"));
if(dev->rx_speed != ATMSAR_SPEED_UNSPEC)
count += sprintf(
&page[count],
"%ld kbps\n",
dev->rx_speed
);
else
count += strlen(strcpy(&page[count], "unknown\n"));
return(count);
}
> [...]
> > > - "return" is not a function.
> >
> > Not even for() or while(). But doesn't they look cute this way?
>
> No.
>
> for (), while (), return rc;
...
> [...]
> > > - consider 'goto' to handle the errors instead of deep nesting
> >
> > I prefer not using goto when not required to. Nesting is far
> more readable
> > to my opinion.
>
> OTOH, it makes ugly code to have it fit in a 80 columns console.
>
> [...]
> > Anyway, which are the functions you are objecting?
>
> atmSend. Probably others.
>
> If you can make the code look like existing in-kernel code (not fs/cifs
> please) say network or ata driver code and you do not need goto, it's fine
> too.
Mmmmh. I'll check it out.
> > > - +const atmsar_aalops_t opsAALR = {
> > > + ATM_AAL0,
> > > + "raw",
> > > -> use .foo = baz instead.
> >
> > atmasr_aalops_t is not an exported structure (you'll find just an opaque
> > definition in include/linux/atmsar.h), so it is not meant to be
> statically
> > declared by device drivers. But I guess that the problem is readability,
> > right?
>
> struct foo zoy {
> .bar= barbar,
> .baz= bazbaz,
> .quuz = ...
> };
...
> [...]
> > May I ask if this is just your own contribution or if you are
> in charge of
> > something in the linux and/or linux-atm projects?
>
> /me scratches head
>
> http://ww.google.com/search?hl=en&q=romieu+linux+cabal
That was to give the right wedge to your hints. If you were just around this
list, your hints had a different value than if you were a committer. Am I wrong?
Thanks,
---
Giampaolo Tomassoni - IT Consultant
Piazza VIII Aprile 1948, 4
I-53044 Chiusi (SI) - Italy
Ph: +39-0578-21100
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Potential IPSec DoS/Kernel Panic with 2.6.13
On 9/4/05, Matt LaPlante <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:linux-kernel- > > [EMAIL PROTECTED] On Behalf Of Herbert Xu > > Sent: Sunday, September 04, 2005 4:24 AM > > To: Matt LaPlante > > Cc: linux-kernel@vger.kernel.org > > Subject: Re: Potential IPSec DoS/Kernel Panic with 2.6.13 > > > > Matt LaPlante <[EMAIL PROTECTED]> wrote: > > > > > > network connectivity on my router. Upon further inspection I noticed > > the > > > packet had actually caused a kernel panic (visible only on the monitor, > > now > > > also unresponsive). > > > > Thanks for the report. I'll try to track it down. > > > > If you could jot down the important bits of the panic message > > (IP, Call-Trace) it would help me find the problem much quicker. > > I'd be more than happy to help you track this one down. The problem here is > that the panic scrolls up and off the screen after which the system is > unusable. Is there a way for me to capture it or redirect it somewhere that > I can read it? I can also include my kernel config or any other system > details of interest. Thanks. > serial console over a cross-over cable to a second box. netconsole will let you put the console on a different box over the network. console on line printer will let you have a permanent record of the console output on paper. See Documentation/serial-console.txt Documentation/networking/netconsole.txt the help entry for "config LP_CONSOLE" (in drivers/char/Kconfig) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: R: [ATMSAR] Request for review - update #1
On Sunday 04 September 2005 19:36, Giampaolo Tomassoni wrote: [snip] > > This may be true for AAL5 support, which is the way by which data is > actually transferred between ADSL DSLAMs and CPE equipment. > > This may not be generally true, however: most providers are already > delivering internet+voice solutions over ADSL channels (here in Italy, in > example, Telecom offers Alice Mia, which is an ADSL line with internet > access and VoIP for added voice capabilities). Albeit the voice part of > these solutions are actually based on VoIP technology, it is not the best > way to do this. In the future, I believe we will easily see internet + > voice sols based over AAL5 + AAL2/3, or even multi voice channels over > AAL2/3 over ADSL (replacing ISDN PRIs and multi-BRIs -based lines for PABX > connection). > > When (and if) that will happen, we will probabily need a kernel-based > solution since cell timing and QoS is a much stricter requirement with > non-AAL5 encodings, such that it is easier to attain from inside the kernel > than from userland. > > So, I'm not that shure all the ATM code is to be stripped out of the > kernel. Maybe it can be done with the PPPoATM network interface. But > probably it can't be done with the ATM core and the ATM SAR code. Wherever > the latter will be in ATMUSB, in ATMSAR or in a device driver. The above is a decent technical justification for why the code is generally required; it's set my mind at rest, I thought maybe this was only for the speedtouch modem crew. I was aware of ATM's ability to interleave data and "digital voice" services; ATM is widely deployed across Europe in preparation for "pure digital" consumer telephony.. My primary concern with the ATM code is that it's not (yet) an often used part of the kernel; there are a number of viable applications out there, but most can happily use linux-atm and/or pppd. I can see VoIP clients doing the same. However, for embedded or non-pure-client purposes, there's a reason for an in-kernel implementation. I don't know enough about the applications of the "ATM stack" versus using a userspace library, so I think as long as the patch is cleaned up and can be reused, it's okay to put in the kernel. > > The PPPoATM module is a network interface. It stays on the other side of > the ATM world: [netif] <-> [PPPoATM] <-> [atmif] <-> [ATM] <-> [ATMSAR] <-> > [device driver]. I'm not a PPPoATM expert, but it may probably be possible > to have all the PPPoATM code in userland. But the [ATM] <-> [ATMSAR] <-> > [device driver] chain is probably too close to hardware to gain any benefit > by "userlanding" it. > I agree, if there are users beyond the speedtouch modem, it may make sense to have this code in the kernel. Thanks for fielding my questions. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: R: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1
Giampaolo Tomassoni wrote: -Messaggio originale- Da: Francois Romieu [mailto:[EMAIL PROTECTED] Inviato: domenica 4 settembre 2005 17.33 A: Giampaolo Tomassoni Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Oggetto: Re: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1 ...omissis... I'd be happily surprized to see more documented ADSL PCI/USB device in the near future. :o( OT Question. What about an open adsl device? The linux community had been bumped out by the adsl market for at least a couple of years, and nobody knows (or tells) why... That could be a definitive answer. Is there anybody interested in this? The problem is that lot's of new devices implement part of their dsp function in the kernel space instead of in the device. And as company don't want to publish their dsp algorith and open source it, we can't have open source driver for it. That the case for bewan device (that even include a libm in their source) and for pulsar pci device... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] Re: [RFC] [patch 0/18] remap_file_pages protection support (for UML), try 3
On Friday 02 September 2005 23:02, Hugh Dickins wrote: > On Fri, 26 Aug 2005, Blaisorblade wrote: > > * The first 2 patches modify the PTE encoding macros and start preparing > > the VM for the new situation (i.e. VMA which have variable protections, > > which are called VM_NONUNIFORM. I dropped the early VM_MANYPROTS name). > What a pity: please revert. VM_NONUNIFORM sounds impressive, but might > mean all kinds of things, maybe to do with NUMA. VM_MANYPROTS is good, > it says what it means. Ok. Btw, before I forget: I assume I should redo the patches rather than fix what you say on top of mine, (at least when not changing behaviour), right? > > * Patch 11 is a big simplification. Since we must encode the PTE's on > > swapout like in VM_NONLINEAR vmas, the simplest way to reuse the existing > > code is to make sure that VM_NONUNIFORM vmas are also marked as > > VM_NONLINEAR. > In some places you seem to say that you (UML) only need VM_MANYPROTS vmas > linear, in other places you seem to say that your VM_MANYPROTS vmas will > be nonlinear. I've no idea which way round it is. Perhaps the "non" > sometimes goes missing (another reason to avoid NONUNIFORM). > I wrote that yesterday. Thanks, you've cleared it up in private mail: > the VM_MANYPROTS vmas that UML wants are VM_NONLINEAR anyway. > Yes, I see your dilemma there: you rightly want to avoid adding bloat > by distinguishing cases that you don't need distinguished; but equally > rightly fear that someone somewhere will start using the VM_MANYPROTS > for other reasons, and hit the inefficiencies of VM_NONLINEAR > unnecessarily. I share your uncertainty, I don't have an immediate > feel for the right direction on that. We'll see later if we can cater to this case without messing up zap_pte_range as I did in last patch (that is the only one with which I was able to break something - not in the version I sent, however). > > *) No more usage of a new syscall slot: to use the new interface, > > application will use the new MAP_NOINHERIT flag I've added. I've still > > the patches to use the old -mm ABI, if there's any reason they're needed. > I'm glad you've scrapped the new syscall slot, that really put me off > the old patch (though I was probably being silly about it). This way > is much better, but again I quarrel with your naming. > "Inherit" is about parents and children, this is not; and furthermore, > some UNIXes had a MAP_INHERIT (see asm-alpha/mman.h) which was about > passing an mmap across exec. Your MAP_NOINHERIT has nothing to do > with that. MAP_MANYPROTS would help us to follow the trail more > easily (though it's true that you can't actually pass many prots > in to a single remap_file_pages call). MAP_CHGPROT? MAP_CHANGEPROT? MAP_REPROT? VM_MANYPROTS is internal name, so there's no reason to have the same name either. > > Subject: [patch 01/18] remap_file_pages protection support: uml, i386, > > x64 bits > > > > Update pte encoding macros for UML, i386 and x86-64. > > Also, add the MAP_NOINHERIT flag to arch headers. > > Well, I don't find your patch division very helpful, since you introduce > these without us seeing what use is made of them. And the MAP_NOINHERIT > additions cover a different subset of arches (ppc, ppc64, s390 in there): > those should be in some other patch. For this patch, I joined up everything because people get scared when they see 39 patches (and I've not really removed code, apart for things which were introduced and later rewritten, just changed the presentation between the two sends). > Usually we just do the i386 arch first, and supply some other patch(es) > for all the others. But you've good reason to start with UML too, and > it makes sense to include x86_64 along too if you're happy to do so. > But it'll probably waste your time and mine to go on discussng patch > division, let's leave it at that. > > *** remap_file_pages protection support: improvement for UML bits > > Recover one bit by additionally using _PAGE_NEWPROT. Since I wasn't sure > > this would work, I've split this out, but it has worked well. We rely on > > the fact that pte_newprot always checks first if the PTE is marked > > present. > And we never hear of _PAGE_NEWPROT or pte_newprot again. Ah, they're > already defined in and peculiar to UML, I see. Well, if this some > UML improvement change, please put that in a separate UML patch. As above, I joined altogether more patches to reduce noise. And after proper unit testing and checking, it was safe anyway to join it. > > -#define pte_to_pgoff(pte) (pte_val(pte) >> 4) > > +#define pte_to_pgoff(pte) (((pte_val(pte) >> 6) << 1) | ((pte_val(pte) > > >> 2) & 0x1)) +#define pte_to_pgprot(pte) \ > > + __pgprot((pte_val(pte) & (_PAGE_RW | _PAGE_PROTNONE)) \ > > + | ((pte_val(pte) & _PAGE_PROTNONE) ? 0 : \ > > + (_PAGE_USER | _PAGE_PRESENT)) | _PAGE_ACCESSED) > It took me a long time to get past this! But it's not your fault > at all, you
R: R: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1
> -Messaggio originale- > Da: matthieu castet [mailto:[EMAIL PROTECTED] > Inviato: domenica 4 settembre 2005 21.11 > > ...omissis... > > The problem is that lot's of new devices implement part of their dsp > function in the kernel space instead of in the device. > And as company don't want to publish their dsp algorith and open source > it, we can't have open source driver for it. > > That the case for bewan device (that even include a libm in their > source) and for pulsar pci device... Nonono: I meant exactly to do an open card with an open dsp software. Next time hardware producers will think twice before refraining from disclosing card details... After all, most producers didn't ever need to disclose their firmware as long as it is a binary file to be uploaded to the card. But still it took a lot of time to have a working ADSL driver under Linux, just because producers didn't want to disclose port assignments and the like. I.e.: they preferred not to disclose anything instead that just refraining to disclose the firmware, which would had to be enough for their purposes. This is a behaviour that the linux community shall discourage. Designing an open hardware and software solution for ADSL connection would be a great way to avoid something like this in the future... You don't disclose? I offer an alternative which bypasses you. The matter is not so easy, however: the ADSL standard is complex and dsp software has to take into account a lot of ADSL "flavors" (DSLAM producers often offer enhancements to the standard way), but it shouldn't be too difficult to the linux community to put together the needed gray matter... Cheers, giampaolo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: i386: kill !4KSTACKS
On Sun, Sep 04, 2005 at 07:12:33PM +0200, Bas Westerbaan wrote: > > Yes you are. You're asking for 4KSTACKS config option to maintained > > and it is not something you get for free. Besides, if it is indeed > > ripped out of mainline kernel, you can always keep it a separate patch > > for ndiswrapper. > > Though 4K stacks are used a lot, they probably aren't used on all > configurations yet. Other situations may arise where 8K stacks may be > preferred. It is too early to kill 8K stacks imho. Please name situations where 8K stacks may be preferred that do not involve binary-only modules. > Bas Westerbaan cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Sun, Sep 04, 2005 at 04:23:04AM -0400, Lee Revell wrote: > On Sun, 2005-09-04 at 09:36 +0200, Stefan Smietanowski wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Lee Revell wrote: > > > On Fri, 2005-09-02 at 02:39 +0200, Adrian Bunk wrote: > > > > > >>4Kb kernel stacks are the future on i386, and it seems the problems it > > >>initially caused are now sorted out. > > >> > > >>Does anyone knows about any currently unsolved problems? > > > > > > > > > ndiswrapper > > > > While I agree ndiswrapper has a use ... I don't think we should > > base kernel development upon messing with something that is designed > > to run a windows driver in linux ... > > Good point, but I don't think we should needlessly render people's > hardware inoperable either. The NdisWrapper FAQ already tells you that you need a patch for some of the binary-only Windows drivers that require more than 8kB stacks. And the fact that NdisWrapper is mostly working hinders the development of open source drivers for this hardware. > Lee cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
R: R: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1
> -Messaggio originale- > Da: matthieu castet [mailto:[EMAIL PROTECTED] > Inviato: domenica 4 settembre 2005 21.11 > > ...omissis... > > The problem is that lot's of new devices implement part of their dsp > function in the kernel space instead of in the device. > And as company don't want to publish their dsp algorith and open source > it, we can't have open source driver for it. > > That the case for bewan device (that even include a libm in their > source) and for pulsar pci device... Nonono: I meant exactly to do an open card with an open dsp software. Next time hardware producers will think twice before refraining from disclosing card details... After all, most producers didn't ever need to disclose their firmware as long as it is a binary file to be uploaded to the card. But still it took a lot of time to have a working ADSL driver under Linux, just because producers didn't want to disclose port assignments and the like. I.e.: they preferred not to disclose anything instead that just refraining to disclose the firmware, which would had to be enough for their purposes. This is a behaviour that the linux community shall discourage. Designing an open hardware and software solution for ADSL connection would be a great way to avoid something like this in the future... You don't disclose? I offer an alternative which bypasses you. The matter is not so easy, however: the ADSL standard is complex and dsp software has to take into account a lot of ADSL "flavors" (DSLAM producers often offer enhancements to the standard way), but it shouldn't be too difficult to the linux community to put together the needed gray matter... Anyway, all these speculations are definitely OT. Sorry about that. Cheers, giampaolo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: nfs4 client bug
On 9/4/05, Francois Romieu <[EMAIL PROTECTED]> wrote: > Bret Towe <[EMAIL PROTECTED]> : > [...] > > after moving some files on the server to a new location then trying to > > add the files > > to xmms playlist i found the following in dmesg after xmms froze > > wonder how many more items i can find... > > The system includes some binary only stuff. Please contact your vendor > or provide the traces for a configuration wherein the relevant module > was not loaded after boot. It may make sense to get in touch with > [EMAIL PROTECTED] then. the 'binary only stuff' is ati-drivers kernel module and it crashs with or without it ill provide a 'untainted' trace as soon as i can repeat the bug again > -- > Ueimor > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
On Sunday 04 September 2005 03:28, Andrew Morton wrote: > If there is already a richer interface into all this code (such as a > syscall one) and it's feasible to migrate the open() tricksies to that API > in the future if it all comes unstuck then OK. That's why I asked (thus > far unsuccessfully): > >Are you saying that the posix-file lookalike interface provides >access to part of the functionality, but there are other APIs which are >used to access the rest of the functionality? If so, what is that >interface, and why cannot that interface offer access to 100% of the >functionality, thus making the posix-file tricks unnecessary? There is no such interface at the moment, nor is one needed in the immediate future. Let's look at the arguments for exporting a dlm to userspace: 1) Since we already have a dlm in kernel, why not just export that and save 100K of userspace library? Answer: because we don't want userspace-only dlm features bulking up the kernel. Answer #2: the extra syscalls and interface baggage serve no useful purpose. 2) But we need to take locks in the same lockspaces as the kernel dlm(s)! Answer: only support tools need to do that. A cut-down locking api is entirely appropriate for this. 3) But the kernel dlm is the only one we have! Answer: easily fixed, a simple matter of coding. But please bear in mind that dlm-style synchronization is probably a bad idea for most cluster applications, particularly ones that already do their synchronization via sockets. In other words, exporting the full dlm api is a red herring. It has nothing to do with getting cluster filesystems up and running. It is really just marketing: it sounds like a great thing for userspace to get a dlm "for free", but it isn't free, it contributes to kernel bloat and it isn't even the most efficient way to do it. If after considering that, we _still_ want to export a dlm api from kernel, then can we please take the necessary time and get it right? The full api requires not only syscall-style elements, but asynchronous events as well, similar to aio. I do not think anybody has a good answer to this today, nor do we even need it to begin porting applications to cluster filesystems. Oracle guys: what is the distributed locking API for RAC? Is the RAC team waiting with bated breath to adopt your kernel-based dlm? If not, why not? Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1
On Sat, Sep 03, 2005 at 01:06:32PM -0700, Andrew Morton wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote: > > > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Andrew, > > > > > > > > it seems you dropped > > > > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's > > > > zero mentioning of this dropping in the changelog of 2.6.13-mm1. > > > > > > > > Can you explain why you did silently drop it? > > > > > > It spat rejects and when I looked at the putative removal date I just > > > didn't believe it anyway. Send a rediffed one if you like, but > > > October 2005 is unrealistic. > > > > That the date is no longer realistic is clear. What disappoints me is > > that you didn't mention in the changelog of 2.6.13-mm1 where I'd have > > noticed it. > > Sometimes I can't be bothered getting into email threads over relatively > unimportant stuff. Usually it's related to the number of bugs we have. This is not about email threads. You send a changelog when you announce a new -mm kernel. Why didn't you simply mention that you dropped this patch due to rejects in the changelog you are sending? > > It semms I need my own bookkeeping of patches I sent that are in -mm to > > notice when they get lost. > > This is called "quilt". > > > The only positive side effect of this is that > > I can use this to push you harder to forward some patches of me to Linus > > that stay unforwarded in -mm for several months... > > A single release cycle is 2-3 months. And I'm talking about patches waiting in -mm for more than 5 months. > I'll probably be dropping some of the patches which unexport symbols, btw. > ANy ones which aren't really, really obvious. We have a process for this. You accept patches into -mm, and without any new issues with these patches you tell me more than five months later "I'll probably be dropping some of the patches which unexport symbols, btw."? If this is how my work is appreciated here I'll better stop wasting part of my spare time and unsubscribe from linux-kernel. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On 03.09.2005 [18:14:48 +1000], Con Kolivas wrote:
> On Sat, 3 Sep 2005 18:06, Russell King wrote:
> > On Sat, Sep 03, 2005 at 06:01:08PM +1000, Con Kolivas wrote:
> > > On Sat, 3 Sep 2005 17:58, Russell King wrote:
> > > > On Sat, Sep 03, 2005 at 04:13:10PM +1000, Con Kolivas wrote:
> > > > > Noone's ignoring you.
> > > > >
> > > > > What we need to do is ensure that dynamic ticks is working properly
> > > > > on x86 and worth including before anything else. If and when we
> > > > > confirm this it makes sense only then to try and merge code from the
> > > > > other 2 architectures to as much common code as possible as no doubt
> > > > > we'll be modifying other architectures we're less familiar with. At
> > > > > that stage we will definitely want to tread even more cautiously at
> > > > > that stage.
> > > >
> > > > dyntick has all the hallmarks of ending up another mess just like the
> > > > "generic" (hahaha) irq stuff in kernel/irq - it's being developed in
> > > > precisely the same way - by ignore non-x86 stuff.
> > > >
> > > > I can well see that someone will say "ok, this is ready, merge it"
> > > > at which point we then end up with multiple differing userspace
> > > > methods of controlling it depending on the architecture, but
> > > > multiple differing kernel interfaces as well.
> > > >
> > > > Indeed, you seem to be at the point where you'd like akpm to merge
> > > > it. That sets alarm bells ringing if you haven't considered these
> > > > issues.
> > > >
> > > > I want to avoid that. Just because a couple of people say "we'll
> > > > deal with that later" it's no guarantee that it _will_ happen. I
> > > > want to ensure that ARM doesn't get fscked over again like it did
> > > > with the generic IRQ crap.
> > >
> > > Ok I'll make it clearer. We don't merge x86 dynticks to mainline till all
> > > are consolidated in -mm.
> >
> > Does this mean you're seriously going to rewrite bits of it after
> > you've spent what seems like months sorting out all the problems
> > currently being found?
> >
> > Excuse me for being stupid, but I somehow don't see that happening.
> > Those months would be effectively wasted effort, both on the side
> > of the people working on the patches and those testing them.
>
> I've personally been on this code for 3 separate days in total and have no
> deadline or requirement for this to go in ever so I should stop speaking on
> behalf of the others.
To join in this conversation late:
I've got a few ideas that I think might help push Con's patch coalescing
efforts in an arch-independent fashion.
First of all, and maybe this is just me, I think it would be good to
make the dyn_tick_timer per-interrupt source, as opposed to each arch?
Thus, for x86, we would have a dyn_tick_timer structure for the PIT,
APIC, ACPI PM-timer and the HPET. These structures could be put in
arch-specific timer.c files (there currently is not one for x86, I
believe). Then, at compilation time, the appropriate structure would be
linked to the arch-generic code. That should make the arch-independent
code simple to implement (I do have some patches in the works, but it's
slow going, right now, sorry). I think ARM and s390 could perhaps use
this infrastructure as well?
Also, I am a bit confused by the use of "dynamic-tick" to describe these
changes. To me, these are all NO_IDLE_HZ implementations, as they are
only invoked from cpu_idle() (or their equivalent) routines. I know this
is true of s390 and the x86 code, and I believe it is true of the ARM
code? If it were dynamic-tick, I would think we would be adjusting the
timer interrupt frequency continuously (e.g., at the end of
__run_timers() and at every call to {add,mod,del}_timer()). I was
working on a patch which did some renaming to no_idle_hz_timer, etc.,
but it's mostly code churn :)
Con, wrt to the x86 implementation, I think the max_skip field should be
a member of the interrupt source (dyn_tick_timer) structure, as opposed
to the state. This would require dyn_tick_reprogram_timer() to change
slightly: either push the max_skip check into arch-specific code (and
then have arch_reprogram() return the actual number of jiffies
programmed to skip) or simply change the check conditional.
Also, what exactly the purpose of conditional_run_local_timers()? It
seems identical to run_local_timers(), except you check for inequality
before potentially raising the softirq. It seems like the conditional
check in run_timer_softirq() [the TIMER_SOFTIRQ callback] will achieve
the same thing? And, in fact, I think that conditional is always true?
At the end of __run_timers, base->timer_jiffies should be greater than
jiffies by 1.
In any case, sorry for all the words and no code... I will try and
rectify that soon. I think it *is* possible to do some architecting now,
so that other architectures can also easily implement no_idle_hz.
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
Re: RFC: i386: kill !4KSTACKS
> > Though 4K stacks are used a lot, they probably aren't used on all > > configurations yet. Other situations may arise where 8K stacks may be > > preferred. It is too early to kill 8K stacks imho. > > Please name situations where 8K stacks may be preferred that do not > involve binary-only modules. I meant that there could be situations, which have not yet been found, where it could be preferred to use 8K stacks instead of 4K. When you switch from having 8K stacks as default to 4K stacks without possibility for 8K stacks you'd possibly encounter these yet to be found situations. When on the other hand the 4K stacks are set as default, leaving the option in, instead of removing it, these possible situations, when found, could be resolved (temporarilly) by switching back to 8K stacks. After a while having 4K stacks as default would be a better time to decide whether to remove the option or not instead of now. -- Bas Westerbaan http://blog.w-nz.com/ GPG Public Keys: http://w-nz.com/keys/bas.westerbaan.asc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm tree
On Sun, Sep 04, 2005 at 01:16:00PM -0700, Andrew Morton wrote:
> unsigned long __copy_to_user_ll(void __user *to, const void *from, unsigned
> long n)
> {
> BUG_ON((long) n < 0);
Ehh? It's unsigned. This will never be true.
> +unsigned long
> +__copy_from_user_ll_nocache(void *to, const void __user *from, unsigned
> long n)
> +{
> +BUG_ON((long)n < 0);
Ditto.
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On Sun, Sep 04, 2005 at 01:10:54PM -0700, Nishanth Aravamudan wrote:
> I've got a few ideas that I think might help push Con's patch coalescing
> efforts in an arch-independent fashion.
Note that ARM contains cleanups on top of Tony's original work, on
which the x86 version is based.
Basically, Tony submitted his ARM version, we discussed it, fixed up
some locking problems and simplified it (it contained multiple
structures which weren't necessary, even in multiple timer-based systems).
I'd be really surprised if any architecture couldn't use what ARM has
today - in other words, this is the only kernel-side interface:
#ifdef CONFIG_NO_IDLE_HZ
#define DYN_TICK_SKIPPING (1 << 2)
#define DYN_TICK_ENABLED(1 << 1)
#define DYN_TICK_SUITABLE (1 << 0)
struct dyn_tick_timer {
unsigned intstate; /* Current state */
int (*enable)(void);/* Enables dynamic tick */
int (*disable)(void); /* Disables dynamic tick */
void(*reprogram)(unsigned long); /* Reprograms the timer */
int (*handler)(int, void *, struct pt_regs *);
};
void timer_dyn_reprogram(void);
#else
#define timer_dyn_reprogram() do { } while (0)
#endif
> First of all, and maybe this is just me, I think it would be good to
> make the dyn_tick_timer per-interrupt source, as opposed to each arch?
> Thus, for x86, we would have a dyn_tick_timer structure for the PIT,
> APIC, ACPI PM-timer and the HPET. These structures could be put in
> arch-specific timer.c files (there currently is not one for x86, I
> believe).
Each timer source should have its own struct dyn_tick_timer. On x86,
maybe it makes sense having a pointer in the init_timer_opts or timer_opts
structures?
> I think ARM and s390 could perhaps use this infrastructure as well?
ARM already has a well thought-out encapsulation which is 100% suited to
its needs - which are essentially the same as x86 - the ability to select
one of several timer sources at boot time.
I would suggest having a good look at the ARM implementation. See:
include/asm-arm/mach/time.h (bit quoted above)
arch/arm/kernel/irq.c (to update system time before calling any irq handler)
arch/arm/kernel/time.c (initialisation and sysfs interface, etc)
arch/arm/mach-sa1100/time.c, arch/arm/mach-pxa/time.c, and
arch/arm/mach-omap1/time.c (dyntick machine class implementations).
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GFS, what's remaining
Hi! > - read-only mount > - "specatator" mount (like ro but no journal allocated for the mount, > no fencing needed for failed node that was mounted as specatator) I'd call it "real-read-only", and yes, that's very usefull mount. Could we get it for ext3, too? Pavel -- if you have sharp zaurus hardware you don't need... you know my address - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On 04.09.2005 [21:26:16 +0100], Russell King wrote:
> On Sun, Sep 04, 2005 at 01:10:54PM -0700, Nishanth Aravamudan wrote:
> > I've got a few ideas that I think might help push Con's patch coalescing
> > efforts in an arch-independent fashion.
>
> Note that ARM contains cleanups on top of Tony's original work, on
> which the x86 version is based.
>
> Basically, Tony submitted his ARM version, we discussed it, fixed up
> some locking problems and simplified it (it contained multiple
> structures which weren't necessary, even in multiple timer-based systems).
Make sense. Thanks for the quick feedback!
> I'd be really surprised if any architecture couldn't use what ARM has
> today - in other words, this is the only kernel-side interface:
>
> #ifdef CONFIG_NO_IDLE_HZ
>
> #define DYN_TICK_SKIPPING (1 << 2)
> #define DYN_TICK_ENABLED(1 << 1)
> #define DYN_TICK_SUITABLE (1 << 0)
>
> struct dyn_tick_timer {
> unsigned intstate; /* Current state */
> int (*enable)(void);/* Enables dynamic tick */
> int (*disable)(void); /* Disables dynamic tick */
> void(*reprogram)(unsigned long); /* Reprograms the timer
> */
> int (*handler)(int, void *, struct pt_regs *);
> };
>
> void timer_dyn_reprogram(void);
> #else
> #define timer_dyn_reprogram() do { } while (0)
> #endif
That looks great! So I guess I'm just suggesting moving this from
include/asm-arch/mach/time.h to arch-independent headers? Perhaps
timer.h is the best place for now, as it already contains the
next_timer_interrupt() prototype (which probably should be in the #ifdef
with timer_dyn_reprogram()).
> > First of all, and maybe this is just me, I think it would be good to
> > make the dyn_tick_timer per-interrupt source, as opposed to each arch?
> > Thus, for x86, we would have a dyn_tick_timer structure for the PIT,
> > APIC, ACPI PM-timer and the HPET. These structures could be put in
> > arch-specific timer.c files (there currently is not one for x86, I
> > believe).
>
> Each timer source should have its own struct dyn_tick_timer. On x86,
> maybe it makes sense having a pointer in the init_timer_opts or timer_opts
> structures?
Well, I know John Stultz is not a big fan of timer_opts, and is trying
to get rid of it :) timer_opts is supposed to be for timesources, I
believe, which are distinct from interrupt sources (e.g., TSC, Cyclone,
etc.), whereas I think dyn-tick is dealing with interrupt sources. I
guess if hardware (like the acpi_pm) can do both, there could be some
sort of inter-hooking.
> > I think ARM and s390 could perhaps use this infrastructure as well?
>
> ARM already has a well thought-out encapsulation which is 100% suited to
> its needs - which are essentially the same as x86 - the ability to select
> one of several timer sources at boot time.
>
> I would suggest having a good look at the ARM implementation. See:
> include/asm-arm/mach/time.h (bit quoted above)
> arch/arm/kernel/irq.c (to update system time before calling any irq handler)
> arch/arm/kernel/time.c (initialisation and sysfs interface, etc)
> arch/arm/mach-sa1100/time.c, arch/arm/mach-pxa/time.c, and
> arch/arm/mach-omap1/time.c (dyntick machine class implementations).
Yeah, I took a quick look before sending out my mail, but obviously need
to study it more. Thanks for the pointers! I guess that the time.h,
irq.c and time.c bits could all (or mostly) be done in arch-independent
code? I agree that your encapsulation seems to be suited to most arch's
use of NO_IDLE_HZ.
Overall, though, do you agree it would be best to have the common code
in a common file? If so, I'll work harder on getting some patches out.
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
