Re: Wireless support
--Lee Revell <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 15:56:06 -0400): > On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote: >> Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS) >> supported? >> > > Wow, Google has really declined in quality. I got zero hits for > "Linksys WUSB 54G linux". Then I found this page on my own. > > (from http://ndiswrapper.sourceforge.net/mediawiki/index.php/List) > > Card: Linksys #[WUSB54G], 802.11b/g, USB 2.0 -- [link here|List#WUSB54G] > * Chipset: Prism54 > * usbid: 5041:2234 > * Driver: Linksys Windows XP driver > http://www.linksys.com/download/default.asp > * Other: Works smoothly, of course ;) - this is the device the USB > extension was originally developed for. WEP is running, WPA is > supported using wpa_supplicant 0.2.5. No problems with both 1.1 > and 2.0 host controllers. As with many other USB devices, no > success with 2.4 kernels so far. Try to use 2.6.7 or better. > There is a native driver for Prism54 that is working on USB > support. View its status at Prism54.org > > Sorry for the WOB. And if anyone from Google is reading, WTF? It doesn't actually say it works on Linux. Perhaps you wanted mysticgooglepsychic.com? ;-) I don't think it is reasonable to expect google to know what ndiswrapper is ... or perhaps it just has a taste filter installed? ;-) M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Highmemory Problem with RHEL3 .... 2.4.21-5.ELsmp
Fawad Lateef wrote: Hello, I m facing a problem in RHEL3 (2.4.21-5.ELsmp) kernel while using kmap_atomic on the pages reserved at the boot time At the boot time I reserved pages above 2GB for later use by my module . And when I was using those reserved pages through kmap_atomic system hangs; although kmap_atomic successfully returns me the virtual address but when I use that virtual address like in memcpy the system hangs . I m unable to findout why it is happening in RHEL3 kernel Plz help me in this regard IIRC 2.4.21 has some highmem bugs that have since been fixed. But, it sounds like you might be doing something quite unusual. Code would definitely give people a better idea of what might be wrong. You should definitely consider moving to 2.6 to get a better response. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Highmemory Problem with RHEL3 .... 2.4.21-5.ELsmp
On 8/7/05, Fawad Lateef <[EMAIL PROTECTED]> wrote: > Hello, > > I m facing a problem in RHEL3 (2.4.21-5.ELsmp) kernel while using > kmap_atomic on the pages reserved at the boot time Unless you can reproduce this in a current kernel.org kernel (2.6.13-rc6), then you probably should contact RedHat for support. 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/
[patch] IPV4 spinlock_casting
Fix a compile error in net/ipv4/route.c when RT patch is applied:
LD .tmp_vmlinux1
net/built-in.o(.text+0x19058): In function `rt_check_expire':
net/ipv4/route.c:628: undefined reference to `__bad_spinlock_type'
net/built-in.o(.text+0x1907a):net/ipv4/route.c:661: undefined reference to
`__bad_spinlock_type'
net/built-in.o(.text+0x1918b): In function `rt_run_flush':
net/ipv4/route.c:684: undefined reference to `__bad_spinlock_type'
net/built-in.o(.text+0x191a3):net/ipv4/route.c:688: undefined reference to
`__bad_spinlock_type'
net/built-in.o(.text+0x193b9): In function `rt_garbage_collect':
net/ipv4/route.c:821: undefined reference to `__bad_spinlock_type'
net/built-in.o(.text+0x193e7):net/ipv4/route.c:853: more undefined references
to `__bad_spinlock_type' follow
make: *** [.tmp_vmlinux1] Error 1
Problem is related to the RT PICK_OP function.
Adds explicit casting to spinlock_t (whatever that happens to be for the
given .config)
Signed-off-by: Sven-Thorsten Dietrich <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc4-RT-V0.7.52-14/net/ipv4/route.c
===
--- linux-2.6.13-rc4-RT-V0.7.52-14.orig/net/ipv4/route.c
+++ linux-2.6.13-rc4-RT-V0.7.52-14/net/ipv4/route.c
@@ -228,7 +228,7 @@
rt_hash_locks = kmalloc(sizeof(spinlock_t) * RT_HASH_LOCK_SZ,
GFP_KERNEL); \
if (!rt_hash_locks) panic("IP: failed to allocate
rt_hash_locks\n"); \
for (i = 0; i < RT_HASH_LOCK_SZ; i++) \
- spin_lock_init(_hash_locks[i]); \
+ spin_lock_init((spinlock_t *) _hash_locks[i]); \
}
#else
# define rt_hash_lock_addr(slot) NULL
@@ -625,7 +625,7 @@
if (*rthp == 0)
continue;
- spin_lock(rt_hash_lock_addr(i));
+ spin_lock((spinlock_t *) rt_hash_lock_addr(i));
while ((rth = *rthp) != NULL) {
if (rth->u.dst.expires) {
/* Entry is expired even if it is in use */
@@ -658,7 +658,7 @@
rt_free(rth);
#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */
}
- spin_unlock(rt_hash_lock_addr(i));
+ spin_unlock((spinlock_t *) rt_hash_lock_addr(i));
/* Fallback loop breaker. */
if (time_after(jiffies, now))
@@ -681,11 +681,11 @@
get_random_bytes(_hash_rnd, 4);
for (i = rt_hash_mask; i >= 0; i--) {
- spin_lock_bh(rt_hash_lock_addr(i));
+ spin_lock_bh((spinlock_t *) rt_hash_lock_addr(i));
rth = rt_hash_table[i].chain;
if (rth)
rt_hash_table[i].chain = NULL;
- spin_unlock_bh(rt_hash_lock_addr(i));
+ spin_unlock_bh((spinlock_t *) rt_hash_lock_addr(i));
for (; rth; rth = next) {
next = rth->u.rt_next;
@@ -818,7 +818,7 @@
k = (k + 1) & rt_hash_mask;
rthp = _hash_table[k].chain;
- spin_lock_bh(rt_hash_lock_addr(k));
+ spin_lock_bh((spinlock_t *) rt_hash_lock_addr(k));
while ((rth = *rthp) != NULL) {
if (!rt_may_expire(rth, tmo, expire)) {
tmo >>= 1;
@@ -850,7 +850,7 @@
goal--;
#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */
}
- spin_unlock_bh(rt_hash_lock_addr(k));
+ spin_unlock_bh((spinlock_t *)rt_hash_lock_addr(k));
if (goal <= 0)
break;
}
@@ -920,7 +920,7 @@
rthp = _hash_table[hash].chain;
- spin_lock_bh(rt_hash_lock_addr(hash));
+ spin_lock_bh((spinlock_t *) rt_hash_lock_addr(hash));
while ((rth = *rthp) != NULL) {
#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED
if (!(rth->u.dst.flags & DST_BALANCED) &&
@@ -946,7 +946,7 @@
rth->u.dst.__use++;
dst_hold(>u.dst);
rth->u.dst.lastuse = now;
- spin_unlock_bh(rt_hash_lock_addr(hash));
+ spin_unlock_bh((spinlock_t *)rt_hash_lock_addr(hash));
rt_drop(rt);
*rp = rth;
@@ -987,7 +987,7 @@
if (rt->rt_type == RTN_UNICAST || rt->fl.iif == 0) {
int err = arp_bind_neighbour(>u.dst);
if (err) {
- spin_unlock_bh(rt_hash_lock_addr(hash));
+ spin_unlock_bh((spinlock_t *)rt_hash_lock_addr(hash));
if (err != -ENOBUFS) {
rt_drop(rt);
@@ -1028,7 +1028,7 @@
}
#endif
rt_hash_table[hash].chain = rt;
- spin_unlock_bh(rt_hash_lock_addr(hash));
Highmemory Problem with RHEL3 .... 2.4.21-5.ELsmp
Hello, I m facing a problem in RHEL3 (2.4.21-5.ELsmp) kernel while using kmap_atomic on the pages reserved at the boot time At the boot time I reserved pages above 2GB for later use by my module . And when I was using those reserved pages through kmap_atomic system hangs; although kmap_atomic successfully returns me the virtual address but when I use that virtual address like in memcpy the system hangs . I m unable to findout why it is happening in RHEL3 kernel Plz help me in this regard -- Fawad Lateef P.S. My memory reservation and later using that memory through kmap_atomic works well on the kernels other than RHEL3 2.4.21-e.ELsmp .. the page reservation was done in the arch/i386/mm/init.c file in function one_highpage_init .. I have Machine with 16GB RAM and 2 - Xeon 2.4GHz Processors . - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech Quickcam Express USB Address Aquisition Issues
> Sorry, I didn't even check the link. Try the driver from: > > http://www.saillard.org/linux/pwc/ > > Which seems to work better. > > -- > Cheers, > Alistair. Err, mine's a logitech camera, why is everyone recommending philips drivers :P? Chris White pgprj9VJsZJCX.pgp Description: PGP signature
2.6.12.3 lockup with lots of D state processes
I have a feeling this might be related back to this issue... http://www.uwsg.iu.edu/hypermail/linux/kernel/0507.1/1518.html As a reminder: we've been running a number of IBM x235 machines with 6G of RAM with a 2.6.12.3 kernel fine for a couple of weeks now. Last night one of the machines started locking up. We could still ssh into the machine, and run some commands (free, uptime, etc), but lots of commands would just lock up and never return (ps, top, etc). The machine mostly runs a cyrus imap server with a number of reiserfs partitions. The partitions are all mounted as below: /dev/sda4 on /var/spool/imap type reiserfs (rw,noatime,nodiratime,nolargeio=1,notail) A full sysrq-t output (700k+) and kernel config are available here: http://robm.fastmail.fm/kernel/t8/ This time it definitely is a full one. In times past it's been bigger than our 1M dmesg buffer. The trace seems to show lots of procs like this: lmtpd D F27E2A40 0 16479 1 16480 16451 (NOTLB) dcb49e98 0086 0008 f27e2a40 f7878b1c f7c9fdfc c016a9d2 f7c9fdfc c0585800 c4293520 4448 06aa7882 000227d8 c4293520 c04c0bc0 f27e2a40 f27e2b64 0002 0001 f7c9fdfc f7f30580 Call Trace: [] dput+0x32/0x1b0 [] __down+0x88/0x100 [] default_wake_function+0x0/0x20 [] __down_failed+0x7/0xc [] .text.lock.namei+0xc4/0x1f8 [] filp_open+0x36/0x60 [] sys_open+0x35/0x70 [] syscall_call+0x7/0xb And a few looking something like this: pop3d D E67AA020 0 16368 1 16376 16296 (NOTLB) d2c27bac 0086 0008 e67aa020 c02b5177 f785a220 0282 c02b52ab 2085a000 c4293520 1a7f 8e0dd38c 000227d7 c4293520 c04c0bc0 e67aa020 e67aa144 c03bffc5 0002 8000 d2c27ba0 Call Trace: [] e100_xmit_frame+0x147/0x300 [] e100_xmit_frame+0x27b/0x300 [] qdisc_restart+0x15/0x1f0 [] queue_log_writer+0x5d/0x80 [] default_wake_function+0x0/0x20 [] do_journal_begin_r+0x1ca/0x2b0 [] ip_queue_xmit+0x425/0x4c0 [] ip_queue_xmit+0x447/0x4c0 [] journal_begin+0x8e/0xe0 [] reiserfs_dirty_inode+0x48/0x90 [] current_fs_time+0x50/0x70 [] __mark_inode_dirty+0x2d/0x170 [] inode_update_time+0xaf/0xc0 [] __generic_file_aio_write_nolock+0x514/0x5f0 [] __link_path_walk+0xadc/0xd40 [] tcp_sendmsg+0x39d/0x1000 [] dput+0x32/0x1b0 [] kmap_high+0x18/0x1e0 [] __generic_file_write_nolock+0x9e/0xc0 [] __d_lookup+0x109/0x140 [] dput+0x32/0x1b0 [] __link_path_walk+0xadc/0xd40 [] autoremove_wake_function+0x0/0x40 [] generic_file_write+0x4e/0xc0 [] reiserfs_file_write+0x17f/0x190 [] link_path_walk+0x97/0xd0 [] copy_to_user+0x60/0x70 [] cp_new_stat64+0xf3/0x110 [] default_llseek+0xbb/0xd0 [] vfs_write+0x8e/0xf0 [] sys_write+0x3d/0x70 [] syscall_call+0x7/0xb As an additional, we have applied this patch to the kernel to try and work around a previously identified deadlock situation in reiserfs. --- file.c~ 2004-10-02 12:29:33.223660850 +0400 +++ file.c 2004-10-08 10:03:03.001561661 +0400 @@ -1137,6 +1137,8 @@ return result; } +return generic_file_write(file, buf, count, ppos); + if ( unlikely((ssize_t) count < 0 )) return -EINVAL; Does this new lockup appear to be a remanifestation of the old problem, or does it appear to be something new... Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Aug 7, 2005, at 21:13:54, Kyle Moffett wrote: On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote: _However_ there is an unrelated problem with some panels, including some of the 17": The panel doesn't always "sync" properly. This seem to be related to some subtle timing issue in the LVDS code but I don't know exactly what yet. You can usually get it back by repeately turning the backlight all the way down (which shuts the panel off) and back up until it "catches". Hmm. This doesn't really fit as my issues are very reproducible. The behaviour under stock Debian 2.6.8 is identical during reboots and after fblevel 0 ; sleep X ; fblevel 15. Likewise, stock 2.6.11, 2.6.12.4, and 2.6.13-rc5, although I'm just getting back to testing things. Damn. As soon as I say this, I go back and am completely unable to make 2.6.13-rc5 reproduce the issue. *grumble* black magic *grumble* :-D. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 5
On Mon, Aug 08, 2005 at 11:30:23AM +1000, Con Kolivas wrote: > Tony said he had it lying around somewhere and needed to find time to dust it > off and get it up to speed. PPC64 is on my ToDo list as well. Will take it up after the dyn-tick is cleaned up for SMP. -- Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockups with netconsole on e1000 on media insertion
On Sun, 2005-08-07 at 23:12 +0200, John Bäckstrand wrote: > Steven Rostedt wrote: > > I don't have the card, so I can't test it. But if this works (after > > removing the previous patch) then this is the better solution. > > I can confirm that this alone does not work for the simple > unplug/re-plug cycle I described, it still locks up hard. Tried this > alone on -rc6. Darn it. If I had a e1000 I could debug it. I have other methods of logging than printks in all there varieties (see relayfs and friends). I still believe that the e1000_netpoll is not turning on the queue for some reason and the netpoll_send_skb is locking up because of that. Especially since Andi's patch fixes the problem. In e1000_clean_tx_irq, which I added to the e1000_netpoll call, has the following lines: if(unlikely(cleaned && netif_queue_stopped(netdev) && netif_carrier_ok(netdev))) netif_wake_queue(netdev); The netif_queue_stopped is true, since that causes the looping in netpoll_send_pkt. So either it didn't clean any buffers (cleaned is false) or netif_carrier_ok is false. I don't know what the e1000 does when you pull the cable while it's transmitting, does it call the e1000_down? If so it could cause the carrier_ok to fail. Oh well, someone with a e1000 card will need to look into this. The problem should be easily found. Good luck. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch] i386: build.c: Write out larger system size to bootsector
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch allows build.c to write out the full system size to the bootsector
for system sizes larger than about 1 MB (1048560 bytes) by using another byte
(a 4th byte would allow system sizes larger than 268 MB).
Signed-off-by: Frank Sorenson <[EMAIL PROTECTED]>
- --- a/arch/i386/boot/tools/build.c2005-08-07 18:08:29.0 -0600
+++ b/arch/i386/boot/tools/build.c 2005-08-07 18:09:51.0 -0600
@@ -177,7 +177,8 @@
die("Output: seek failed");
buf[0] = (sys_size & 0xff);
buf[1] = ((sys_size >> 8) & 0xff);
- - if (write(1, buf, 2) != 2)
+ buf[2] = ((sys_size >> 16) & 0xff);
+ if (write(1, buf, 3) != 3)
die("Write of image length failed");
return 0; /* Everything is OK
*/
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC9r+raI0dwg4A47wRAtXCAKCm3f2Afx/SC5H+6HJz2JzM9cA1ZQCgjMbg
qt7Rmo23aWfG1cvsZrcsQvA=
=0iHd
-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: [ck] Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 5
Along the same lines, is there an x86_64 patch around? On August 07, 2005 21:30, Con Kolivas wrote: > On Mon, 8 Aug 2005 11:20 am, Kyle Moffett wrote: > > On Aug 7, 2005, at 19:51:25, Con Kolivas wrote: > > > On Mon, 8 Aug 2005 02:58, Srivatsa Vaddagiri wrote: > > >> Con, > > >> I am afraid until SMP correctness is resolved, then this is not > > >> in a position to go in (unless you want to enable it only for UP, > > >> which > > >> I think should not be our target). I am working on making this work > > >> correctly on SMP systems. Hopefully I will post a patch soon. > > > > > > Great! I wasn't sure what time frame you meant when you last > > > posted. I won't > > > do anything more, leaving this patch as it is, and pass the baton > > > to you. > > > > I'm curious what has happened to the PPC side of the patch. IIRC, > > someone > > was working on such a port, but it seems to have been lost along the way > > at some point. Is there any additional information on that patch? > > Tony said he had it lying around somewhere and needed to find time to dust > it off and get it up to speed. > > Cheers, > Con > ___ > [EMAIL PROTECTED] > ck mailing list. Please reply-to-all when posting. > If replying to an email please reply below the original message. > http://bhhdoa.org.au/mailman/listinfo/ck -- Gabriel Devenyi [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH C] gdth: remove GDTIOCTL_OSVERS
On Mon, Aug 08, 2005 at 02:28:29AM +0400, Alexey Dobriyan wrote:
>...
> --- linux-vanilla/drivers/scsi/gdth.c 2005-08-08 02:16:47.0 +0400
> +++ linux-gdth/drivers/scsi/gdth.c2005-08-08 02:19:59.0 +0400
> @@ -5411,18 +5411,6 @@ static int gdth_ioctl(struct inode *inod
> return -EFAULT;
> break;
>}
> -
> - case GDTIOCTL_OSVERS:
> - {
> -gdth_ioctl_osvers osv;
> -
> -osv.version = (unchar)(LINUX_VERSION_CODE >> 16);
> -osv.subversion = (unchar)(LINUX_VERSION_CODE >> 8);
> -osv.revision = (ushort)(LINUX_VERSION_CODE & 0xff);
> -if (copy_to_user(argp, , sizeof(gdth_ioctl_osvers)))
> -return -EFAULT;
> -break;
> - }
>...
Not that I'd like this, but you know that this is a userspace-visible
change?
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: [linux-pm] [PATCH] Workqueue freezer support.
Hi. On Mon, 2005-08-08 at 11:27, Con Kolivas wrote: > On Mon, 8 Aug 2005 10:46 am, Nigel Cunningham wrote: > > Hi. > > > > Sorry for the slow response. Busy still. > > > > On Sat, 2005-08-06 at 15:06, Patrick Mochel wrote: > > > On Fri, 5 Aug 2005, Nigel Cunningham wrote: > > > > Hi. > > > > > > > > I finally found some time to finish this off. I don't really like the > > > > end result - the macros looked clearer to me - but here goes. If it > > > > looks okay, I'll seek sign offs from each of the affected driver > > > > maintainers and from Ingo. Anyone else? > > > > > > What are your feelings about this: http://lwn.net/Articles/145417/ ? > > > > I'm sure it could work, but I do worry a little about the possibilities > > for exploits. It seems to me that if someone can get root, they an > > insmod a module that could schedule any kind of work via any process. > > Tracing that sort of security hole could be intractable. Christoph, is > > that something you've considered/have thoughts on? Perhaps I'm just > > being paranoid :> > > If someone gets root access it means you're already exploited. Yeah, true. Ok. Lame thought :> Nigel > Cheers, > Con -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i386 No-Idle-Hz aka Dynamic-Ticks 5
On Mon, 8 Aug 2005 11:20 am, Kyle Moffett wrote: > On Aug 7, 2005, at 19:51:25, Con Kolivas wrote: > > On Mon, 8 Aug 2005 02:58, Srivatsa Vaddagiri wrote: > >> Con, > >> I am afraid until SMP correctness is resolved, then this is not > >> in a position to go in (unless you want to enable it only for UP, > >> which > >> I think should not be our target). I am working on making this work > >> correctly on SMP systems. Hopefully I will post a patch soon. > > > > Great! I wasn't sure what time frame you meant when you last > > posted. I won't > > do anything more, leaving this patch as it is, and pass the baton > > to you. > > I'm curious what has happened to the PPC side of the patch. IIRC, > someone > was working on such a port, but it seems to have been lost along the way > at some point. Is there any additional information on that patch? Tony said he had it lying around somewhere and needed to find time to dust it off and get it up to speed. Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] abstract out bits of ldt.c
* Zachary Amsden ([EMAIL PROTECTED]) wrote: > Doesn't that require 16 pages per CPU? That seems excessive to impose > on a native build. Perhaps we could get away with 1 page per CPU for > the GDT on native boots and bump that up to 16 if compiling for a > virtualized sub-architecture - i.e. move GDT to a page aligned struct > for native (doesn't cost too much), and give it MACH_GDT_PAGES of space > which is defined by the sub-architecture. For Xen, the gdt is one page per cpu (so it's not one page per table entry). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Workqueue freezer support.
On Mon, 8 Aug 2005 10:46 am, Nigel Cunningham wrote: > Hi. > > Sorry for the slow response. Busy still. > > On Sat, 2005-08-06 at 15:06, Patrick Mochel wrote: > > On Fri, 5 Aug 2005, Nigel Cunningham wrote: > > > Hi. > > > > > > I finally found some time to finish this off. I don't really like the > > > end result - the macros looked clearer to me - but here goes. If it > > > looks okay, I'll seek sign offs from each of the affected driver > > > maintainers and from Ingo. Anyone else? > > > > What are your feelings about this: http://lwn.net/Articles/145417/ ? > > I'm sure it could work, but I do worry a little about the possibilities > for exploits. It seems to me that if someone can get root, they an > insmod a module that could schedule any kind of work via any process. > Tracing that sort of security hole could be intractable. Christoph, is > that something you've considered/have thoughts on? Perhaps I'm just > being paranoid :> If someone gets root access it means you're already exploited. Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wireless support
On Sun, 2005-08-07 at 21:20 -0400, Lee Revell wrote: > On Sun, 2005-08-07 at 18:39 -0600, Alejandro Bonilla Beeche wrote: > > On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote: > > > Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS) > > > supported? > > > > > > TIA, > > > > > > Lee > > > > Normally, linksys doesn't care much about Linux and they won't even > > release info for a driver. Yeah, they have some open info for the WRT's > > but the adapters are normally usable with ndiswrapper or Linuxant > > driver. > > > > IMHO, in reference to Wireless adapters, I would get already supported > > ones. > > Well, AFAICT it should be supported by the prism54 driver. Is this not > the case? http://linuxwifi.com/modules/wiwimod/?page=DeviceList Apparently, looks like only the WUSB54G not the WUSB54GS. But that makes me think that it should be supported soon by the prism54. Maybe ask them if they have a clue, or if they have an experimental patch to support it? > Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abstract out bits of ldt.c
> I like these patches. They greatly simplify a lot of the work I
> had anticipated was necessary for Xen. I.e. - LDT / GDT accessors
> are not needed for most updates, only updates to live descriptor
> table entries (for GDT this is TLS, LDT, TSS?, entries and there
> is 1 LDT update case).
I'm just trying to get rid of as much code duplication as possible.
> BTW, Martin, did you see my ldt-accessors patch? It also
> encapsulates that 1 LDT update case you show here, just named
> differently.
I was focussing on creating a whole Xen stack before looking at
your stuff much, then seeing what was common between them, as I
think it's a bit hard to read the current Xen code because of the
copied files. Unfortunately, is going to be harder then I thought
to maintain that stack out of tree, so I wanted to shovel out
the basic refactoring stuff. Then the line got a bit blurred.
Humpf. And this is the easy part. Damn it.
Doing the whole thing and comparing is going to be a total PITA.
Perhaps the right thing to do is go one file at a time, and sync
up on that basis.
> Yours:
>
> +static inline int install_ldt_entry (__u32 *lp, __u32 entry_1, __u32 entry_2)
> +{
> + *lp = entry_1;
> + *(lp+1) = entry_2;
> + return 0;
> +}
>
> Mine:
>
> +static inline void write_ldt_entry(void *ldt, int entry, __u32 entry_a,
> __u32 entry_b)
> +{
> + __u32 *lp = (__u32 *)((char *)ldt + entry*8);
> + *lp = entry_a;
> + *(lp+1) = entry_b;
> +}
>
>
> They both work, but mine does not assume page aligned LDTs (necessary
> to extract entry number). This is moot right now because LDTs are
> page aligned anyway in Linux. I actually don't care which one we
> use, but it might be even nicer if we got one with C type checking
> (struct desc_struct for ldt).
Heh, is similar, considering we're working from completely different
angles. I'm just refactoring the current code without changing it
too much at first, we can make it more robust later. otherwise it's
going to be a pig to review if we mix those up.
> I think introducing mach-xen headers is a bit premature though - lets
> get the interface nailed down first so that the hypervisor developers
> have time to settle the include/asm-i386/mach-xxx files without
> dealing unneeded churn onto the maintainers.
I can easily leave those bits out. There's going to be lots of bits common
with std i386, and bits that are common amongst the hypervisor layers,
then bits that are specific. Hopefully more bits that are common, but
still.
Humpf. I shall go back into my corner and have a rethink. Will read through
your patches some more, then send you some email.
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Wireless support
On Sun, 2005-08-07 at 18:39 -0600, Alejandro Bonilla Beeche wrote: > On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote: > > Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS) > > supported? > > > > TIA, > > > > Lee > > Normally, linksys doesn't care much about Linux and they won't even > release info for a driver. Yeah, they have some open info for the WRT's > but the adapters are normally usable with ndiswrapper or Linuxant > driver. > > IMHO, in reference to Wireless adapters, I would get already supported > ones. Well, AFAICT it should be supported by the prism54 driver. Is this not the case? Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 5
On Aug 7, 2005, at 19:51:25, Con Kolivas wrote: On Mon, 8 Aug 2005 02:58, Srivatsa Vaddagiri wrote: Con, I am afraid until SMP correctness is resolved, then this is not in a position to go in (unless you want to enable it only for UP, which I think should not be our target). I am working on making this work correctly on SMP systems. Hopefully I will post a patch soon. Great! I wasn't sure what time frame you meant when you last posted. I won't do anything more, leaving this patch as it is, and pass the baton to you. I'm curious what has happened to the PPC side of the patch. IIRC, someone was working on such a port, but it seems to have been lost along the way at some point. Is there any additional information on that patch? Cheers, Kyle Moffett -- Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] abstract out bits of ldt.c
Chris Wright wrote: * Zachary Amsden ([EMAIL PROTECTED]) wrote: Does Xen assume page aligned descriptor tables? I assume from this Yes. patch and snippets I have gathered from others, that is a yes, and other things here imply that DT pages are not shadowed. If so, Xen itself must have live segments in the GDT pages, so how do you allocate space for the per-CPU GDT pages on SMP? early during boot. Doesn't that require 16 pages per CPU? That seems excessive to impose on a native build. Perhaps we could get away with 1 page per CPU for the GDT on native boots and bump that up to 16 if compiling for a virtualized sub-architecture - i.e. move GDT to a page aligned struct for native (doesn't cost too much), and give it MACH_GDT_PAGES of space which is defined by the sub-architecture. Let's take this thread over to [EMAIL PROTECTED] as well. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote: I've got an LCD, and on mine it looks like every third pixel-line gets shifted about 32-64 pixels to the left, and they move with display refresh. My guess is that something is interrupting radeonfb during a critical time in display syncing and forcing the video card to wait too far into the next line before sending pixels. radeonfb is mostly inactive after it has setup the framebuffer and unless you actually draw something, in which case, accel code is called. _However_ there is an unrelated problem with some panels, including some of the 17": The panel doesn't always "sync" properly. This seem to be related to some subtle timing issue in the LVDS code but I don't know exactly what yet. You can usually get it back by repeately turning the backlight all the way down (which shuts the panel off) and back up until it "catches". Hmm. This doesn't really fit as my issues are very reproducible. The behaviour under stock Debian 2.6.8 is identical during reboots and after fblevel 0 ; sleep X ; fblevel 15. Likewise, stock 2.6.11, 2.6.12.4, and 2.6.13-rc5, although I'm just getting back to testing things. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abstract out bits of ldt.c
* Zachary Amsden ([EMAIL PROTECTED]) wrote: > Does Xen assume page aligned descriptor tables? I assume from this Yes. > patch and snippets I have gathered from others, that is a yes, and other > things here imply that DT pages are not shadowed. If so, Xen itself > must have live segments in the GDT pages, so how do you allocate space > for the per-CPU GDT pages on SMP? early during boot. > I think introducing mach-xen headers is a bit premature though - lets > get the interface nailed down first so that the hypervisor developers > have time to settle the include/asm-i386/mach-xxx files without dealing > unneeded churn onto the maintainers. I don't think there's any point in putting mach-xen stuff in either. Can we please discuss these patches in some sane way (say on the virutalization list) so we're not cross-firing at each other. It's just going to be too messy otherwiswe. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abstract out bits of ldt.c
Chris Wright wrote:
* Andrew Morton ([EMAIL PROTECTED]) wrote:
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
xen_make_pages_readonly / xen_make_pages_writable ?
Well we don't want to assume "xen" at this stage. We're faced with a
choice at present: to make the linux->hypervisor interface be some
xen-specific and xen-controlled thing, or to make it a more formal and
controlled kernel interface which talks to a generic hypervisor rather than
assuming it's Xen down there.
No, definietly not. Xen is not appropriate global namespace. Also,
it's not about pages at this point, it's about ldt handling.
I like these patches. They greatly simplify a lot of the work I had
anticipated was necessary for Xen. I.e. - LDT / GDT accessors are not
needed for most updates, only updates to live descriptor table entries
(for GDT this is TLS, LDT, TSS?, entries and there is 1 LDT update case).
BTW, Martin, did you see my ldt-accessors patch? It also encapsulates
that 1 LDT update case you show here, just named differently.
Yours:
+static inline int install_ldt_entry (__u32 *lp, __u32 entry_1, __u32 entry_2)
+{
+ *lp = entry_1;
+ *(lp+1) = entry_2;
+ return 0;
+}
Mine:
+static inline void write_ldt_entry(void *ldt, int entry, __u32 entry_a, __u32
entry_b)
+{
+ __u32 *lp = (__u32 *)((char *)ldt + entry*8);
+ *lp = entry_a;
+ *(lp+1) = entry_b;
+}
They both work, but mine does not assume page aligned LDTs (necessary to
extract entry number). This is moot right now because LDTs are page
aligned anyway in Linux. I actually don't care which one we use, but it
might be even nicer if we got one with C type checking (struct
desc_struct for ldt).
Does Xen assume page aligned descriptor tables? I assume from this
patch and snippets I have gathered from others, that is a yes, and other
things here imply that DT pages are not shadowed. If so, Xen itself
must have live segments in the GDT pages, so how do you allocate space
for the per-CPU GDT pages on SMP?
As long as it doesn't hamper performance or general code sanity, I think it
would be better to make this a well-defined and controlled Linux interface.
Some of the code to do that is starting to accumulate in -mm. Everyone
needs to sit down, take a look at the patches and the proposal and work out
if this is the way to proceed.
We're doing that, but it's splintered and coming in from different angles.
It'd be better to get the story straight then submit patches, IMO.
I think introducing mach-xen headers is a bit premature though - lets
get the interface nailed down first so that the hypervisor developers
have time to settle the include/asm-i386/mach-xxx files without dealing
unneeded churn onto the maintainers.
Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] abstract out bits of ldt.c
--Andrew Morton <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 17:41:29 -0700): > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: >> >> >> >> --Chris Wright <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 >> 16:44:11 -0700): >> >> > * Martin J. Bligh ([EMAIL PROTECTED]) wrote: >> >> Starting on the work to merge xen cleanly as a subarch. >> >> Introduce make_pages_readonly and make_pages_writable where appropriate >> >> for Xen, defined as a no-op on other subarches. Same for >> > >> > Maybe this is a bad name, since make_pages_readonly/writable has >> > intutitive meaning, and then is non-inutitively a no-op (for default). >> >> You're welcome to suggest something else if you want, though it would >> have been easier if you'd done it the first time you saw this patch, >> not now. Going through this stuff multiple times is going to get very >> boring very fast. >> >> xen_make_pages_readonly / xen_make_pages_writable ? >> > > Well we don't want to assume "xen" at this stage. We're faced with a > choice at present: to make the linux->hypervisor interface be some > xen-specific and xen-controlled thing, or to make it a more formal and > controlled kernel interface which talks to a generic hypervisor rather than > assuming it's Xen down there. Yes, more generic than xen would be better. I think mach-xen is probably OK for now, but I agree we should avoid wedging xen_* in generic code callouts. What I'm trying to do right now is rip the whole duplicated files out of the xen patches. > As long as it doesn't hamper performance or general code sanity, I think it > would be better to make this a well-defined and controlled Linux interface. > Some of the code to do that is starting to accumulate in -mm. Everyone > needs to sit down, take a look at the patches and the proposal and work out > if this is the way to proceed. We're faced with a difficult choice - the xen patches are hard to read without refactoring them. On the other hand it's going to be very painful to keep them in sync out of tree whilst doing the refactoring. I'd prefer to merge up some bits as we go, though maybe I should keep those more neutral than this. Sigh ... this is going to be extremely painful whatever we do. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] DVB: lgdt330x frontend: trivial text cleanups
some tiny minor cleanups...
--
Michael Krufky
Two trivial text changes in Kconfig and lgdt330x.c
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
linux/drivers/media/dvb/frontends/Kconfig|2 +-
linux/drivers/media/dvb/frontends/lgdt330x.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -u linux-2.6.13/drivers/media/dvb/frontends/lgdt330x.c
linux/drivers/media/dvb/frontends/lgdt330x.c
--- linux-2.6.13/drivers/media/dvb/frontends/lgdt330x.c 2005-08-07
18:49:20.0 +
+++ linux/drivers/media/dvb/frontends/lgdt330x.c2005-08-07
20:49:18.0 +
@@ -772,7 +772,7 @@
static struct dvb_frontend_ops lgdt3302_ops = {
.info = {
- .name= "LG Electronics LGDT3302/LGDT3303 VSB/QAM Frontend",
+ .name= "LG Electronics LGDT3302 VSB/QAM Frontend",
.type = FE_ATSC,
.frequency_min= 5400,
.frequency_max= 85800,
diff -u linux-2.6.13/drivers/media/dvb/frontends/Kconfig
linux/drivers/media/dvb/frontends/Kconfig
--- linux-2.6.13/drivers/media/dvb/frontends/Kconfig2005-08-07
15:36:35.0 +
+++ linux/drivers/media/dvb/frontends/Kconfig 2005-08-07 20:49:18.0
+
@@ -188,7 +188,7 @@
support this frontend.
config DVB_LGDT330X
- tristate "LGDT3302 or LGDT3303 based (DViCO FusionHDTV Gold)"
+ tristate "LG Electronics LGDT3302/LGDT3303 based"
depends on DVB_CORE
help
An ATSC 8VSB and QAM64/256 tuner module. Say Y when you want
Re: 2.6.13-rc5-mm1
Rogério Brito <[EMAIL PROTECTED]> wrote: > > Thanks Andrew, for including the vfat speedup patch. > > It has really improved a lot the performance of access to directories > having many subdirectories in an external Firewire HD that I have. > > I'd say that if others don't have problems with it, then it should be > in 2.6.13, as far as I am concerned. It's probably a bit late to be able to determine that. This one's 2.6.14 material, sorry. > BTW, everything is working fine with the sbp2/ieee1394 drivers that > are in the mm tree. Good to hear. > It seems that there are some issues with ALSA, though. I will report > back as soon as I see if these are userland problems or not (it worked > fine with vanilla 2.6.13-rc5). OK, thanks for testing and reporting. Our turnaround time for ALSA fixes is not fantastic, really, so any problems which we currently have will probably carry over into 2.6.13. If you can raise a bugzilla record for any problems in -rc6 I'll make sure they aren't forgotten. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Workqueue freezer support.
Hi.
Sorry for the slow response. Busy still.
On Sat, 2005-08-06 at 15:06, Patrick Mochel wrote:
> On Fri, 5 Aug 2005, Nigel Cunningham wrote:
>
> > Hi.
> >
> > I finally found some time to finish this off. I don't really like the
> > end result - the macros looked clearer to me - but here goes. If it
> > looks okay, I'll seek sign offs from each of the affected driver
> > maintainers and from Ingo. Anyone else?
>
> What are your feelings about this: http://lwn.net/Articles/145417/ ?
I'm sure it could work, but I do worry a little about the possibilities
for exploits. It seems to me that if someone can get root, they an
insmod a module that could schedule any kind of work via any process.
Tracing that sort of security hole could be intractable. Christoph, is
that something you've considered/have thoughts on? Perhaps I'm just
being paranoid :>
> It seems like a cleaner way to do things. How would these patches change
> if that were merged?
We would still need some way to mark which threads to freeze, so we'd
still need the same sort of thing as far as kthread_run etc goes.
We'd also still mark unfreezable threads with NOFREEZE and not mark
other threads, so no change there.
The first substantial change I can see would be switching from
try_to_freeze to try_todo_list (could this be 'run_todo_list'? Try
implies failure is possible - if it is possible, why do we ignore
whether it fails?).
The second substantial change would be in the area of the refrigeration
code itself, ala Christoph's patch.
One more question regarding Christoph's patch - would it be worth moving
the refrigerator related code from sched.h to a separate file? We
already have so many things that depend on sched.h, and this will add
more. It will also make maintenance less painful because you won't have
to recompile everything that depends on sched.h when all you did was
modify (say) freezing().
> Concerning the patch specifically:
>
> > diff -ruNp 400-workthreads.patch-old/include/linux/kthread.h
> > 400-workthreads.patch-new/include/linux/kthread.h
> > --- 400-workthreads.patch-old/include/linux/kthread.h 2004-11-03
> > 21:51:12.0 +1100
> > +++ 400-workthreads.patch-new/include/linux/kthread.h 2005-08-03
> > 11:52:01.0 +1000
> > @@ -23,10 +23,20 @@
> > *
> > * Returns a task_struct or ERR_PTR(-ENOMEM).
> > */
> > +struct task_struct *__kthread_create(int (*threadfn)(void *data),
> > + void *data,
> > + unsigned long freezer_flags,
> > + const char namefmt[],
> > + va_list * args);
> > +
>
> When comparing this to this:
>
> > diff -ruNp 400-workthreads.patch-old/include/linux/workqueue.h
> > 400-workthreads.patch-new/include/linux/workqueue.h
> > --- 400-workthreads.patch-old/include/linux/workqueue.h 2005-06-20
> > 11:47:30.0 +1000
> > +++ 400-workthreads.patch-new/include/linux/workqueue.h 2005-08-03
> > 11:49:34.0 +1000
> > @@ -51,9 +51,12 @@ struct work_struct {
> > } while (0)
> >
> > extern struct workqueue_struct *__create_workqueue(const char *name,
> > - int singlethread);
> > -#define create_workqueue(name) __create_workqueue((name), 0)
> > -#define create_singlethread_workqueue(name) __create_workqueue((name), 1)
> > + int singlethread,
> > + unsigned long freezer_flag);
> > +#define create_workqueue(name) __create_workqueue((name), 0, 0)
> > +#define create_nofreeze_workqueue(name) __create_workqueue((name), 0,
> > PF_NOFREEZE)
> > +#define create_singlethread_workqueue(name) __create_workqueue((name), 1,
> > 0)
> > +#define create_nofreeze_singlethread_workqueue(name)
> > __create_workqueue((name), 1, PF_NOFREEZE)
>
> And to this:
>
>
> > static struct task_struct *create_workqueue_thread(struct workqueue_struct
> > *wq,
> > - int cpu)
> > + int cpu,
> > + unsigned long freezer_flags)
> > {
>
> There is a slight discrepancy in the API changes. Obviously, we don't want
> to change every caller of create_workqueue() to support this. But, perhaps
> you could standardize the handling of the freezer flags (by e.g. creating
> a separate _nofreeze version for each).
Missed that one, sorry.
> Also, functions that take a va_list parameter pass the structure (array)
> rather than the pointer. See the definition of vprintk() in
> include/linux/kernel.h for an example.
Thanks for the pointer.
Nigel
>
> Thanks,
>
>
> Pat
>
> __
> ___
> linux-pm mailing list
> [EMAIL PROTECTED]
> https://lists.osdl.org/mailman/listinfo/linux-pm
--
Evolution.
Re: [PATCH] abstract out bits of ldt.c
* Andrew Morton ([EMAIL PROTECTED]) wrote: > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > > xen_make_pages_readonly / xen_make_pages_writable ? > > Well we don't want to assume "xen" at this stage. We're faced with a > choice at present: to make the linux->hypervisor interface be some > xen-specific and xen-controlled thing, or to make it a more formal and > controlled kernel interface which talks to a generic hypervisor rather than > assuming it's Xen down there. No, definietly not. Xen is not appropriate global namespace. Also, it's not about pages at this point, it's about ldt handling. > As long as it doesn't hamper performance or general code sanity, I think it > would be better to make this a well-defined and controlled Linux interface. > Some of the code to do that is starting to accumulate in -mm. Everyone > needs to sit down, take a look at the patches and the proposal and work out > if this is the way to proceed. We're doing that, but it's splintered and coming in from different angles. It'd be better to get the story straight then submit patches, IMO. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc5-mm1
Thanks Andrew, for including the vfat speedup patch. It has really improved a lot the performance of access to directories having many subdirectories in an external Firewire HD that I have. I'd say that if others don't have problems with it, then it should be in 2.6.13, as far as I am concerned. BTW, everything is working fine with the sbp2/ieee1394 drivers that are in the mm tree. It seems that there are some issues with ALSA, though. I will report back as soon as I see if these are userland problems or not (it worked fine with vanilla 2.6.13-rc5). Thanks, Rogério. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] abstract out bits of ldt.c
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > > > > --Chris Wright <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 16:44:11 > -0700): > > > * Martin J. Bligh ([EMAIL PROTECTED]) wrote: > >> Starting on the work to merge xen cleanly as a subarch. > >> Introduce make_pages_readonly and make_pages_writable where appropriate > >> for Xen, defined as a no-op on other subarches. Same for > > > > Maybe this is a bad name, since make_pages_readonly/writable has > > intutitive meaning, and then is non-inutitively a no-op (for default). > > You're welcome to suggest something else if you want, though it would > have been easier if you'd done it the first time you saw this patch, > not now. Going through this stuff multiple times is going to get very > boring very fast. > > xen_make_pages_readonly / xen_make_pages_writable ? > Well we don't want to assume "xen" at this stage. We're faced with a choice at present: to make the linux->hypervisor interface be some xen-specific and xen-controlled thing, or to make it a more formal and controlled kernel interface which talks to a generic hypervisor rather than assuming it's Xen down there. As long as it doesn't hamper performance or general code sanity, I think it would be better to make this a well-defined and controlled Linux interface. Some of the code to do that is starting to accumulate in -mm. Everyone needs to sit down, take a look at the patches and the proposal and work out if this is the way to proceed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wireless support
On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote: > Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS) > supported? > > TIA, > > Lee Normally, linksys doesn't care much about Linux and they won't even release info for a driver. Yeah, they have some open info for the WRT's but the adapters are normally usable with ndiswrapper or Linuxant driver. IMHO, in reference to Wireless adapters, I would get already supported ones. .Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] abstract out bits of ldt.c
On Sun, 2005-08-07 at 16:20 -0700, Martin J. Bligh wrote: > Starting on the work to merge xen cleanly as a subarch. > Introduce make_pages_readonly and make_pages_writable where appropriate > for Xen, defined as a no-op on other subarches. Same for > add_context_to_unpinned and del_context_from_unpinned. > Abstract out install_ldt_entry() ... > cpumask_t mask; > preempt_disable(); > + make_pages_readonly(pc->ldt, (pc->size * LDT_ENTRY_SIZE) / > + PAGE_SIZE); > load_LDT(pc); > mask = cpumask_of_cpu(smp_processor_id()); > if (!cpus_equal(current->mm->cpu_vm_mask, mask)) > smp_call_function(flush_ldt, NULL, 1, 1); > preempt_enable(); > #else > + make_pages_readonly(pc->ldt, (pc->size * LDT_ENTRY_SIZE) / > + PAGE_SIZE); You do that (size * LDT_ENTRY_SIZE / PAGE_SIZE) operation an awfully large number of times. Could you consider introducing a little helper, say ldt_size_pages()? Or, could you have a helper like make_ldt_readonly()? You don't have to export it, just use it in that one file. > This will do have no effect whatsover on platforms other than xen. ... > + memset(>context, 0, sizeof(mm->context)); > init_MUTEX(>context.sem); > - mm->context.size = 0; Could you please explain what this is for? It doesn't appear to be part of the abstraction. Every call path I can see to init_new_context() is immediately preceded by mm_alloc(), which memsets the entire mm. The context is a direct member of mm_struct, and should be zeroed along with the mm_alloc() memset. So, this seems a bit superfluous. In any future patches that you might post, please do one thing per patch, it makes them much easier to audit. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pci_find_device and pci_find_slot mark as deprecated
This marks these functions as deprecated not to use in latest drivers (it doesn't use reference counts and the device returned by it can disappear in any time). This patch was sent yet on: 28 Jul 2005 (without pci_find_slot removing and wrapping lines) Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> diff --git a/include/linux/pci.h b/include/linux/pci.h --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -328,9 +328,11 @@ void pci_setup_cardbus(struct pci_bus *b /* Generic PCI functions exported to card drivers */ -struct pci_dev *pci_find_device (unsigned int vendor, unsigned int device, const struct pci_dev *from); +struct pci_dev *pci_find_device (unsigned int vendor, unsigned int device, + const struct pci_dev *from) __deprecated; struct pci_dev *pci_find_device_reverse (unsigned int vendor, unsigned int device, const struct pci_dev *from); -struct pci_dev *pci_find_slot (unsigned int bus, unsigned int devfn); +struct pci_dev *pci_find_slot (unsigned int bus, unsigned int devfn) + __deprecated; int pci_find_capability (struct pci_dev *dev, int cap); int pci_find_ext_capability (struct pci_dev *dev, int cap); struct pci_bus * pci_find_next_bus(const struct pci_bus *from); -- 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/
[PATCH] DVB: lgdt330x frontend: some bug fixes & add lgdt3303 support
For 2.6.13, if possible. Patch generated against 2.6.13-rc6
--
Michael Krufky
- Structural changes within lgdt330x driver, framework now supports
both chips... tested OK on lgdt3302 and lgdt3303.
- Add LG/TUA6034 dvb_pll_desc for ATSC with LG TDVS-H062F & DViCO FusionHDTV5.
- Fixed LGDT330X signal strength: For now, always set it to 0.
- Corrected LGDT330X boundary condition error in read_snr: dB calculation.
Signed-off-by: Mac Michaels <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
-
linux/drivers/media/dvb/frontends/dvb-pll.c | 16
linux/drivers/media/dvb/frontends/dvb-pll.h |1
linux/drivers/media/dvb/frontends/lgdt330x.c | 549 +-
linux/drivers/media/dvb/frontends/lgdt330x.h | 16
linux/drivers/media/dvb/frontends/lgdt330x_priv.h |8
linux/drivers/media/video/cx88/cx88-dvb.c | 26
6 files changed, 443 insertions(+), 173 deletions(-)
diff -u linux-2.6.13/drivers/media/dvb/frontends/lgdt330x.c
linux/drivers/media/dvb/frontends/lgdt330x.c
--- linux-2.6.13/drivers/media/dvb/frontends/lgdt330x.c 2005-08-07
15:36:35.0 +
+++ linux/drivers/media/dvb/frontends/lgdt330x.c2005-08-07
18:35:08.0 +
@@ -1,11 +1,8 @@
/*
- *Support for LGDT3302 & LGDT3303 (DViCO FusionHDTV Gold) - VSB/QAM
+ *Support for LGDT3302 and LGDT3303 - VSB/QAM
*
*Copyright (C) 2005 Wilson Michaels <[EMAIL PROTECTED]>
*
- *Based on code from Kirk Lapray <[EMAIL PROTECTED]>
- * Copyright (C) 2005
- *
*This program is free software; you can redistribute it and/or modify
*it under the terms of the GNU General Public License as published by
*the Free Software Foundation; either version 2 of the License, or
@@ -25,11 +22,13 @@
/*
* NOTES ABOUT THIS DRIVER
*
- * This driver supports DViCO FusionHDTV Gold under Linux.
+ * This Linux driver supports:
+ * DViCO FusionHDTV 3 Gold-Q
+ * DViCO FusionHDTV 3 Gold-T
+ * DViCO FusionHDTV 5 Gold
*
* TODO:
- * BER and signal strength always return 0.
- * Include support for LGDT3303
+ * signal strength always returns 0.
*
*/
@@ -41,7 +40,6 @@
#include
#include "dvb_frontend.h"
-#include "dvb-pll.h"
#include "lgdt330x_priv.h"
#include "lgdt330x.h"
@@ -70,55 +68,37 @@
u32 current_frequency;
};
-static int i2c_writebytes (struct lgdt330x_state* state,
- u8 addr, /* demod_address or pll_address */
+static int i2c_write_demod_bytes (struct lgdt330x_state* state,
u8 *buf, /* data bytes to send */
int len /* number of bytes to send */ )
{
- u8 tmp[] = { buf[0], buf[1] };
struct i2c_msg msg =
- { .addr = addr, .flags = 0, .buf = tmp, .len = 2 };
- int err;
+ { .addr = state->config->demod_address,
+ .flags = 0,
+ .buf = buf,
+ .len = 2 };
int i;
+ int err;
- for (i=1; ii2c, , 1)) != 1) {
- printk(KERN_WARNING "lgdt330x: %s error (addr %02x <-
%02x, err == %i)\n", __FUNCTION__, addr, buf[0], err);
+ printk(KERN_WARNING "lgdt330x: %s error (addr %02x <-
%02x, err = %i)\n", __FUNCTION__, msg.buf[0], msg.buf[1], err);
if (err < 0)
return err;
else
return -EREMOTEIO;
}
- tmp[0]++;
- }
- return 0;
-}
-
-#if 0
-static int i2c_readbytes (struct lgdt330x_state* state,
- u8 addr, /* demod_address or pll_address */
- u8 *buf, /* holds data bytes read */
- int len /* number of bytes to read */ )
-{
- struct i2c_msg msg =
- { .addr = addr, .flags = I2C_M_RD, .buf = buf, .len = len };
- int err;
-
- if ((err = i2c_transfer(state->i2c, , 1)) != 1) {
- printk(KERN_WARNING "lgdt330x: %s error (addr %02x, err ==
%i)\n", __FUNCTION__, addr, err);
- return -EREMOTEIO;
+ msg.buf += 2;
}
return 0;
}
-#endif
/*
* This routine writes the register (reg) to the demod bus
* then reads the data returned for (len) bytes.
*/
-static u8 i2c_selectreadbytes (struct lgdt330x_state* state,
+static u8 i2c_read_demod_bytes (struct lgdt330x_state* state,
enum I2C_REG reg, u8* buf, int len)
{
u8 wr [] = { reg };
@@ -139,7 +119,7 @@
}
/* Software reset */
-int lgdt330x_SwReset(struct lgdt330x_state* state)
+static int lgdt3302_SwReset(struct lgdt330x_state* state)
{
u8 ret;
u8 reset[] = {
@@ -148,23 +128,83 @@
* bits 5-0 are 1 to mask interrupts */
};
- ret = i2c_writebytes(state,
-
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Sun, 7 Aug 2005, Benjamin Herrenschmidt wrote: > On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote: > > On Sun, 7 Aug 2005, Kyle Moffett wrote: > > > On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: > > > > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb > > > > though ... Can you try something like wrapper radeon_write_mode() with > > > > preempt_disable()/preempt_enable() and tell me if it makes a > > > > difference ? > > > > Did not help. The values used to initialize the mode seem to be wrong. > > Copying the aty directory from 2.6.12 did not help, too. > > I don't see how PREEMPT could have any impact there unless you are > experiencing memory corruption... or one of those panels that have so > subtle timing issues that they sometimes don't sync depending on how > many flies you have in your room The wrong values are constant across reboots (see my first mail), and I have a CRT. Can you tell me where the timing values are read? -- E.G.G.E.R.T.: Electronic Guardian Generated for Efficient Repair and Troubleshooting -- http://www.brunching.com/toys/toy-cyborger.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abstract out bits of ldt.c
* Martin J. Bligh ([EMAIL PROTECTED]) wrote: > You're welcome to suggest something else if you want, though it would > have been easier if you'd done it the first time you saw this patch, > not now. Going through this stuff multiple times is going to get very > boring very fast. Sorry, that's my fault, didn't strike me until looking at it this time. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abstract out bits of ldt.c
--Chris Wright <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 16:44:11 -0700): > * Martin J. Bligh ([EMAIL PROTECTED]) wrote: >> Starting on the work to merge xen cleanly as a subarch. >> Introduce make_pages_readonly and make_pages_writable where appropriate >> for Xen, defined as a no-op on other subarches. Same for > > Maybe this is a bad name, since make_pages_readonly/writable has > intutitive meaning, and then is non-inutitively a no-op (for default). You're welcome to suggest something else if you want, though it would have been easier if you'd done it the first time you saw this patch, not now. Going through this stuff multiple times is going to get very boring very fast. xen_make_pages_readonly / xen_make_pages_writable ? M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 5
On Mon, 8 Aug 2005 02:58, Srivatsa Vaddagiri wrote: > On Sun, Aug 07, 2005 at 03:12:21PM +1000, Con Kolivas wrote: > > Respin of the dynamic ticks patch for i386 by Tony Lindgen and Tuukka > > Tikkanen with further code cleanups. Are were there yet? > > Con, > I am afraid until SMP correctness is resolved, then this is not > in a position to go in (unless you want to enable it only for UP, which > I think should not be our target). I am working on making this work > correctly on SMP systems. Hopefully I will post a patch soon. > Will keep you posted of my progress with dynamic tick patch. Great! I wasn't sure what time frame you meant when you last posted. I won't do anything more, leaving this patch as it is, and pass the baton to you. Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Removing maintainer's bad e-mails
This patch removes 2 e-mails, which aren't right and 1 web address, which returns 404. [comtrol was posted by Rolf Eike Beer] It is made in 2.6.13-rc5-mm1, but it should be applicable in other trees too. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> This patch was posted yet on: 21 Jul 2005 diff --git a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS +++ b/MAINTAINERS @@ -204,8 +204,6 @@ S: Maintained ADVANSYS SCSI DRIVER P: Bob Frey -M: [EMAIL PROTECTED] -W: http://www.advansys.com/linux.html L: linux-scsi@vger.kernel.org S: Maintained @@ -1975,7 +1973,6 @@ S:Supported ROCKETPORT DRIVER P: Comtrol Corp. -M: [EMAIL PROTECTED] W: http://www.comtrol.com S: Maintained -- 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: kexec and frame buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric W. Biederman ha scritto: > Anyway I believe you also want to look at include/linux/tty.h > at the screen_info structure. I believe that is where > all of that information is passed. I noticed. Maybe if we fill struct x86_linux_param_header with some values obtained from struct screen_info, we should be able to "score that mid-court prayer" ;) >>I tried to pass --real-mode flag to kexec but my virtual machine doesn't like >>it. When I launch kexec -e, it tells me: "A strange behaviour occourred which >>crashed virtual machine". > > > Cool. I haven't used that code in a long time but it is pretty > trivial code to switches to real mode so I don't really doubt it :) Added to my list-of-things-to-do-after-holydays :) Regards, - -- Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvYmaszkDT3RfMB6AQLPMQf/W3HZbJj50rxI1LOHyw0hhcQZji+gU68R E88xmgbL1fuiQqdqD1vp3gG7uDf9jjE+TjNMQ1qgZr01xHUjV13Jq8e9Lu75S+RZ JgiYJxFKGY/ctl9oFgEraU9Qje1b18dTmYh5G4xfZLNjUFUM1uQowV6CSPLVRadv ucmzduDrqwRBQgN9vSrWPoLio8nbT5ZjxLjaY1z3P3EYXoBs9LLx1bjzLmR7/cVe MP3/BM61CLqflOG9G+ck9yD2RIYnLhvNHDBKt1X+oP+U/iSkzse3XEM/YVny6/3d zAYy8m66o2bPnj/vNcBbroxANTdiXJce8QWayk9a69c26DmjOLnYrQ== =iPn6 -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: [PATCH] abstract out bits of ldt.c
* Martin J. Bligh ([EMAIL PROTECTED]) wrote: > Starting on the work to merge xen cleanly as a subarch. > Introduce make_pages_readonly and make_pages_writable where appropriate > for Xen, defined as a no-op on other subarches. Same for Maybe this is a bad name, since make_pages_readonly/writable has intutitive meaning, and then is non-inutitively a no-op (for default). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.6.13-rc5-git-current (0d317fb72fe3cf0f611608cf3a3015bbe6cd2a66)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexander Nyberg wrote:
> (akpm: a fix for this needs to go into 2.6.13, inotify + nfs
> trivially oopses otherwise, even if inotify isn't actively used)
This patch seems to have fixed it for me.
I upgraded to fdbd22dad31982b64a4e663fd056a8a7cfac9607 and applied this
patch on top of it, and I can't retrigger the oops. (It seemed rather
easy to hit on the other kernel)
So, I guess:
Seems-to-fix-it: Ryan Anderson <[EMAIL PROTECTED]>
> It looks like the following sequence is done in the wrong order.
> When vfs_unlink() is called from sys_unlink() it has taken a ref
> on the inode and sys_unlink() does the last iput() but when called
> from other callsites vfs_unlink() might do the last iput() and
> free inode, so inotify_inode_queue_event() will receive an already
> freed object and dereference an already freed object.
>
> Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
>
> Index: mm/fs/namei.c
> ===
> --- mm.orig/fs/namei.c2005-08-07 12:06:16.0 +0200
> +++ mm/fs/namei.c 2005-08-07 18:17:20.0 +0200
> @@ -1869,8 +1869,8 @@
> /* We don't d_delete() NFS sillyrenamed files--they still exist. */
> if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
> struct inode *inode = dentry->d_inode;
> - d_delete(dentry);
> fsnotify_unlink(dentry, inode, dir);
> + d_delete(dentry);
> }
>
> return 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/
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC9pgyfhVDhkBuUKURAjbSAKCavd7s4zdk/uce1TZ0CX018RGRmgCfXWFI
XjAPhBcEoLyJDWnjk9oI+XI=
=NMc4
-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: 2.6.13-rc3-mm3
--"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005 21:21:30 -0700): > --"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005 > 18:17:33 -0700): >> --Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, July 28, 2005 >> 23:10:29 -0700): >> >>> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we identified earlier with the sched patches ... http://test.kernel.org/9398/debug/console.log >>> >>> Oh, thanks. That's about 8,349 bugs ago and I'd forgotten. >>> Works with mainline still (including -rc4) ... hopefully those patches aren't on their way upstream anytime soon ;-) >>> >>> Well can you identify the offending patch(es)? If so, I'll exterminate >>> them. >> >> scheduler-cache-hot-autodetect.patch, I think. >> >> will double-check. > > Yup, backing out that one patch definitely fixes it. There was an earlier > thread with Ingo about doing some possible debug on it, but to be honest, > I haven't had time to play much beyond the initial ideas we tried. Still broken in 2.6.13-rc5-mm1, any chance you could back this one out until it gets fixed? that way I can still test with that platform (plus it'll stop it from getting accidentally merged ;-)) Thanks, M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] abstract out bits of ldt.c
Starting on the work to merge xen cleanly as a subarch.
Introduce make_pages_readonly and make_pages_writable where appropriate
for Xen, defined as a no-op on other subarches. Same for
add_context_to_unpinned and del_context_from_unpinned.
Abstract out install_ldt_entry().
This will do have no effect whatsover on platforms other than xen.
Compile-tested with every config I can find. Boot tested on i386.
diff -aurpN -X /home/fletch/.diff.exclude virgin/arch/i386/kernel/ldt.c
xen-ldt.c/arch/i386/kernel/ldt.c
--- virgin/arch/i386/kernel/ldt.c 2004-10-24 19:27:13.0 -0700
+++ xen-ldt.c/arch/i386/kernel/ldt.c2005-08-07 10:45:49.0 -0700
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_SMP /* avoids "defined but not used" warnig */
static void flush_ldt(void *null)
@@ -58,16 +59,22 @@ static int alloc_ldt(mm_context_t *pc, i
#ifdef CONFIG_SMP
cpumask_t mask;
preempt_disable();
+ make_pages_readonly(pc->ldt, (pc->size * LDT_ENTRY_SIZE) /
+ PAGE_SIZE);
load_LDT(pc);
mask = cpumask_of_cpu(smp_processor_id());
if (!cpus_equal(current->mm->cpu_vm_mask, mask))
smp_call_function(flush_ldt, NULL, 1, 1);
preempt_enable();
#else
+ make_pages_readonly(pc->ldt, (pc->size * LDT_ENTRY_SIZE) /
+ PAGE_SIZE);
load_LDT(pc);
#endif
}
if (oldsize) {
+ make_pages_writable(oldldt, (oldsize * LDT_ENTRY_SIZE) /
+ PAGE_SIZE);
if (oldsize*LDT_ENTRY_SIZE > PAGE_SIZE)
vfree(oldldt);
else
@@ -82,6 +89,8 @@ static inline int copy_ldt(mm_context_t
if (err < 0)
return err;
memcpy(new->ldt, old->ldt, old->size*LDT_ENTRY_SIZE);
+ make_pages_readonly(new->ldt, (new->size * LDT_ENTRY_SIZE) /
+ PAGE_SIZE);
return 0;
}
@@ -94,14 +103,16 @@ int init_new_context(struct task_struct
struct mm_struct * old_mm;
int retval = 0;
+ memset(>context, 0, sizeof(mm->context));
init_MUTEX(>context.sem);
- mm->context.size = 0;
old_mm = current->mm;
if (old_mm && old_mm->context.size > 0) {
down(_mm->context.sem);
retval = copy_ldt(>context, _mm->context);
up(_mm->context.sem);
}
+ if (retval == 0)
+ add_context_to_unpinned(mm);
return retval;
}
@@ -113,12 +124,16 @@ void destroy_context(struct mm_struct *m
if (mm->context.size) {
if (mm == current->active_mm)
clear_LDT();
+ make_pages_writable(mm->context.ldt,
+ (mm->context.size * LDT_ENTRY_SIZE) /
+ PAGE_SIZE);
if (mm->context.size*LDT_ENTRY_SIZE > PAGE_SIZE)
vfree(mm->context.ldt);
else
kfree(mm->context.ldt);
mm->context.size = 0;
}
+ del_context_from_unpinned(mm);
}
static int read_ldt(void __user * ptr, unsigned long bytecount)
@@ -223,9 +238,7 @@ static int write_ldt(void __user * ptr,
/* Install the new entry ... */
install:
- *lp = entry_1;
- *(lp+1) = entry_2;
- error = 0;
+ error = install_ldt_entry(lp, entry_1, entry_2);
out_unlock:
up(>context.sem);
diff -aurpN -X /home/fletch/.diff.exclude
virgin/include/asm-i386/mach-default/mach_ldt.h
xen-ldt.c/include/asm-i386/mach-default/mach_ldt.h
--- virgin/include/asm-i386/mach-default/mach_ldt.h 1969-12-31
16:00:00.0 -0800
+++ xen-ldt.c/include/asm-i386/mach-default/mach_ldt.h 2005-08-07
10:43:58.0 -0700
@@ -0,0 +1,27 @@
+#ifndef __ASM_MACH_LDT_H
+#define __ASM_MACH_LDT_H
+
+static inline void make_pages_readonly(void *va, unsigned int nr)
+{
+}
+
+static inline void make_pages_writable(void *va, unsigned int nr)
+{
+}
+
+static inline void add_context_to_unpinned(struct mm_struct *mm)
+{
+}
+
+static inline void del_context_from_unpinned(struct mm_struct *mm)
+{
+}
+
+static inline int install_ldt_entry (__u32 *lp, __u32 entry_1, __u32 entry_2)
+{
+ *lp = entry_1;
+ *(lp+1) = entry_2;
+ return 0;
+}
+
+#endif /* __ASM_MACH_LDT_H */
diff -aurpN -X /home/fletch/.diff.exclude
virgin/include/asm-i386/mach-xen/mach_ldt.h
xen-ldt.c/include/asm-i386/mach-xen/mach_ldt.h
--- virgin/include/asm-i386/mach-xen/mach_ldt.h 1969-12-31 16:00:00.0
-0800
+++ xen-ldt.c/include/asm-i386/mach-xen/mach_ldt.h 2005-08-07
10:44:45.0 -0700
@@ -0,0 +1,27 @@
+#ifndef __ASM_MACH_LDT_H
[2.6 patch] remove unused fs/befs/attribute.c
From: Will Dyson <[EMAIL PROTECTED]>
If anyone needs a fully-functional befs driver, the easiest route to
that would probably be getting Haiku's befs driver to compile in
userland as a FUSE fs.
At any rate, attribute.c can go. It is easy enough to add back in if
anyone ever wants to do the (relativly minor) refactoring nessisary to
get it working.
Signed-off-by: Will Dyson <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was sent by Will Dyson on:
- 4 Aug 2005
fs/befs/attribute.c | 117
1 files changed, 117 deletions(-)
--- a/fs/befs/attribute.c Tue Aug 2 13:00:13 2005
+++ /dev/null Thu Aug 4 00:31:20 2005
@@ -1,117 +0,0 @@
-/*
- * linux/fs/befs/attribute.c
- *
- * Copyright (C) 2002 Will Dyson <[EMAIL PROTECTED]>
- *
- * Many thanks to Dominic Giampaolo, author of "Practical File System
- * Design with the Be File System", for such a helpful book.
- *
- */
-
-#include
-#include
-#include
-
-#include "befs.h"
-#include "endian.h"
-
-#define SD_DATA(sd)\
- (void*)((char*)sd + sizeof(*sd) + (sd->name_size - sizeof(sd->name)))
-
-#define SD_NEXT(sd)\
- (befs_small_data*)((char*)sd + sizeof(*sd) + (sd->name_size - \
- sizeof(sd->name) + sd->data_size))
-
-int
-list_small_data(struct super_block *sb, befs_inode * inode, filldir_t filldir);
-
-befs_small_data *
-find_small_data(struct super_block *sb, befs_inode * inode,
-const char *name);
-int
-read_small_data(struct super_block *sb, befs_inode * inode,
-befs_small_data * sdata, void *buf, size_t bufsize);
-
-/**
- *
- *
- *
- *
- *
- */
-befs_small_data *
-find_small_data(struct super_block *sb, befs_inode * inode, const char *name)
-{
- befs_small_data *sdata = inode->small_data;
-
- while (sdata->type != 0) {
- if (strcmp(name, sdata->name) != 0) {
- return sdata;
- }
- sdata = SD_NEXT(sdata);
- }
- return NULL;
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-read_small_data(struct super_block *sb, befs_inode * inode,
- const char *name, void *buf, size_t bufsize)
-{
- befs_small_data *sdata;
-
- sdata = find_small_data(sb, inode, name);
- if (sdata == NULL)
- return BEFS_ERR;
- else if (sdata->data_size > bufsize)
- return BEFS_ERR;
-
- memcpy(buf, SD_DATA(sdata), sdata->data_size);
-
- return BEFS_OK;
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-list_small_data(struct super_block *sb, befs_inode * inode)
-{
-
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-list_attr(struct super_block *sb, befs_inode * inode)
-{
-
-}
-
-/**
- *
- *
- *
- *
- *
- */
-int
-read_attr(struct super_block *sb, befs_inode * inode)
-{
-
-}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] fs/asfs/: make code static
This patch makes needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 29 Jul 2005
- 22 Jul 2005
fs/asfs/asfs_fs.h | 12
fs/asfs/extents.c |4 +++-
fs/asfs/inode.c | 29 ++---
fs/asfs/objects.c |4 +++-
fs/asfs/super.c | 18 +-
5 files changed, 41 insertions(+), 26 deletions(-)
--- linux-2.6.13-rc3-mm1-full/fs/asfs/extents.c.old 2005-07-21
23:04:26.0 +0200
+++ linux-2.6.13-rc3-mm1-full/fs/asfs/extents.c 2005-07-21 23:04:45.0
+0200
@@ -271,7 +271,9 @@
/* Returns created extentbnode - returned_bh need to saved and realesed in
caller funkction! */
-int createextentbnode(struct super_block *sb, u32 key, struct buffer_head
**returned_bh, struct BNode **returned_bnode)
+static int createextentbnode(struct super_block *sb, u32 key,
+struct buffer_head **returned_bh,
+struct BNode **returned_bnode)
{
int errorcode;
--- linux-2.6.13-rc3-mm1-full/fs/asfs/asfs_fs.h.old 2005-07-21
23:06:11.0 +0200
+++ linux-2.6.13-rc3-mm1-full/fs/asfs/asfs_fs.h 2005-07-21 23:10:22.0
+0200
@@ -174,13 +174,6 @@
/* inode.c */
struct inode *asfs_get_root_inode(struct super_block *sb);
void asfs_read_locked_inode(struct inode *inode, void *arg);
-int asfs_create(struct inode *dir, struct dentry *dentry, int mode, struct
nameidata *nd);
-int asfs_mkdir(struct inode *dir, struct dentry *dentry, int mode);
-int asfs_symlink(struct inode *dir, struct dentry *dentry, const char
*symname);
-int asfs_rmdir(struct inode *dir, struct dentry *dentry);
-int asfs_unlink(struct inode *dir, struct dentry *dentry);
-int asfs_rename(struct inode *old_dir, struct dentry *old_dentry,
- struct inode *new_dir, struct dentry *new_dentry);
int asfs_notify_change(struct dentry *dentry, struct iattr *attr);
/* namei */
@@ -221,11 +214,6 @@
/* super.c */
struct super_block *asfs_read_super(struct super_block *sb, void *data,
int silent);
-void asfs_put_super(struct super_block *sb);
-int asfs_statfs(struct super_block *sb, struct kstatfs *buf);
-int asfs_remount(struct super_block *sb, int *flags, char *data);
-struct inode *asfs_alloc_inode(struct super_block *sb);
-void asfs_destroy_inode(struct inode *inode);
/* symlink.c */
int asfs_symlink_readpage(struct file *file, struct page *page);
--- linux-2.6.13-rc3-mm1-full/fs/asfs/inode.c.old 2005-07-21
23:05:25.0 +0200
+++ linux-2.6.13-rc3-mm1-full/fs/asfs/inode.c 2005-07-21 23:22:36.0
+0200
@@ -26,6 +26,18 @@
#include
+#ifdef CONFIG_ASFS_RW
+static int asfs_create(struct inode *dir, struct dentry *dentry,
+ int mode, struct nameidata *nd);
+static int asfs_mkdir(struct inode *dir, struct dentry *dentry, int mode);
+static int asfs_symlink(struct inode *dir, struct dentry *dentry,
+ const char *symname);
+static int asfs_unlink(struct inode *dir, struct dentry *dentry);
+static int asfs_rmdir(struct inode *dir, struct dentry *dentry);
+static int asfs_rename(struct inode *old_dir, struct dentry *old_dentry,
+ struct inode *new_dir, struct dentry *new_dentry);
+#endif /* CONFIG_ASFS_RW */
+
/* Mapping from our types to the kernel */
static struct address_space_operations asfs_aops = {
@@ -277,22 +289,24 @@
return error;
}
-int asfs_create(struct inode *dir, struct dentry *dentry, int mode, struct
nameidata *nd)
+static int asfs_create(struct inode *dir, struct dentry *dentry,
+ int mode, struct nameidata *nd)
{
return asfs_create_object(dir, dentry, mode, it_file, NULL);
}
-int asfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
+static int asfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
{
return asfs_create_object(dir, dentry, mode, it_dir, NULL);
}
-int asfs_symlink(struct inode *dir, struct dentry *dentry, const char *symname)
+static int asfs_symlink(struct inode *dir, struct dentry *dentry,
+ const char *symname)
{
return asfs_create_object(dir, dentry, 0, it_link, symname);
}
-int asfs_rmdir(struct inode *dir, struct dentry *dentry)
+static int asfs_rmdir(struct inode *dir, struct dentry *dentry)
{
asfs_debug("ASFS: %s\n", __FUNCTION__);
@@ -302,7 +316,7 @@
return asfs_unlink(dir, dentry);
}
-int asfs_unlink(struct inode *dir, struct dentry *dentry)
+static int asfs_unlink(struct inode *dir, struct dentry *dentry)
{
struct inode *inode = dentry->d_inode;
int error;
@@ -341,7 +355,8 @@
return 0;
}
-int asfs_rename(struct inode *old_dir, struct dentry *old_dentry, struct inode
*new_dir, struct dentry *new_dentry)
+static int asfs_rename(struct inode *old_dir, struct dentry *old_dentry,
+ struct inode *new_dir,
[2.6 patch] jffs/jffs2: remove wrong function prototypes
This patch removes prototypes for the generic_file_open and
generic_file_llseek functions.
Besides being superfluous because they are already present in fs.h, they
were also wrong because the actual functions aren't weak functions.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 31 Jul 2005
fs/jffs/inode-v23.c |3 ---
fs/jffs2/file.c |3 ---
2 files changed, 6 deletions(-)
--- linux-2.6.13-rc4-mm1-full/fs/jffs/inode-v23.c.old 2005-07-31
18:43:46.0 +0200
+++ linux-2.6.13-rc4-mm1-full/fs/jffs/inode-v23.c 2005-07-31
18:44:15.0 +0200
@@ -1629,9 +1629,6 @@
}
-extern int generic_file_open(struct inode *, struct file *)
__attribute__((weak));
-extern loff_t generic_file_llseek(struct file *, loff_t, int)
__attribute__((weak));
-
static struct file_operations jffs_file_operations =
{
.open = generic_file_open,
--- linux-2.6.13-rc4-mm1-full/fs/jffs2/file.c.old 2005-07-31
18:44:31.0 +0200
+++ linux-2.6.13-rc4-mm1-full/fs/jffs2/file.c 2005-07-31 18:44:40.0
+0200
@@ -21,9 +21,6 @@
#include
#include "nodelist.h"
-extern int generic_file_open(struct inode *, struct file *)
__attribute__((weak));
-extern loff_t generic_file_llseek(struct file *file, loff_t offset, int
origin) __attribute__((weak));
-
static int jffs2_commit_write (struct file *filp, struct page *pg,
unsigned start, unsigned end);
static int jffs2_prepare_write (struct file *filp, struct page *pg,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc4: yenta_socket and swsusp
Hi! > 2. The attached script can produce all sorts of pcmcia related >problems if it is modified where stated - the attached version >seems to work without problems if not modified. Do you want >a bug report filed for this, too? Races in pcmcia, fun :-(. I guess this is going to be slightly hard to reproduce without right hardware :(. 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/
[PATCH C] gdth: remove GDTIOCTL_OSVERS
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
drivers/scsi/gdth.c | 12
drivers/scsi/gdth_ioctl.h |8
2 files changed, 20 deletions(-)
diff -uprN linux-vanilla/drivers/scsi/gdth.c linux-gdth/drivers/scsi/gdth.c
--- linux-vanilla/drivers/scsi/gdth.c 2005-08-08 02:16:47.0 +0400
+++ linux-gdth/drivers/scsi/gdth.c 2005-08-08 02:19:59.0 +0400
@@ -5411,18 +5411,6 @@ static int gdth_ioctl(struct inode *inod
return -EFAULT;
break;
}
-
- case GDTIOCTL_OSVERS:
- {
-gdth_ioctl_osvers osv;
-
-osv.version = (unchar)(LINUX_VERSION_CODE >> 16);
-osv.subversion = (unchar)(LINUX_VERSION_CODE >> 8);
-osv.revision = (ushort)(LINUX_VERSION_CODE & 0xff);
-if (copy_to_user(argp, , sizeof(gdth_ioctl_osvers)))
-return -EFAULT;
-break;
- }
case GDTIOCTL_CTRTYPE:
{
diff -uprN linux-vanilla/drivers/scsi/gdth_ioctl.h
linux-gdth/drivers/scsi/gdth_ioctl.h
--- linux-vanilla/drivers/scsi/gdth_ioctl.h 2005-08-08 02:16:47.0
+0400
+++ linux-gdth/drivers/scsi/gdth_ioctl.h2005-08-08 02:20:19.0
+0400
@@ -10,7 +10,6 @@
#define GDTIOCTL_GENERAL(GDTIOCTL_MASK | 0) /* general IOCTL */
#define GDTIOCTL_DRVERS (GDTIOCTL_MASK | 1) /* get driver version */
#define GDTIOCTL_CTRTYPE(GDTIOCTL_MASK | 2) /* get controller type */
-#define GDTIOCTL_OSVERS (GDTIOCTL_MASK | 3) /* get OS version */
#define GDTIOCTL_HDRLIST(GDTIOCTL_MASK | 4) /* get host drive list */
#define GDTIOCTL_CTRCNT (GDTIOCTL_MASK | 5) /* get controller count */
#define GDTIOCTL_LOCKDRV(GDTIOCTL_MASK | 6) /* lock host drive */
@@ -296,13 +295,6 @@ typedef struct {
unchar channel; /* channel */
} gdth_ioctl_lockchn;
-/* GDTIOCTL_OSVERS */
-typedef struct {
-unchar version; /* OS version */
-unchar subversion; /* OS subversion */
-ushort revision;/* revision */
-} gdth_ioctl_osvers;
-
/* GDTIOCTL_CTRTYPE */
typedef struct {
ushort ionode; /* controller number */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: amd64-agp vs. swsusp
Pavel Machek wrote: I assume it is in -rc6, too; it is long-standing bug and I am not aware of any attempts at fixing it. Please file bug report, assign to me. I've filed it as Bug 5018. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] fix drivers/s390/net/ compilation
Looking at Jan Dittmer's crosscompile site [1], one of the two
architectures where defconfig compiled in 2.6.12.4 but does no longer
compile in 2.6.13-rc6 is s390.
Looking at the build error, it seems s390-use-klist-in-qeth-driver.patch
from -mm was intended to fix this compile error.
I haven't tested whether it is actually enough for getting the s390
defconfig compiling, but it can't make things worse.
[1] http://l4x.org/k/
<-- snip -->
From: Cornelia Huck <[EMAIL PROTECTED]>
From: Martin Schwidesky <[EMAIL PROTECTED]>
Convert qeth to the new klist interface and make it compiling again.
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/s390/net/qeth_main.c | 24
drivers/s390/net/qeth_proc.c | 126 +++
2 files changed, 82 insertions(+), 68 deletions(-)
diff -puN drivers/s390/net/qeth_main.c~s390-use-klist-in-qeth-driver
drivers/s390/net/qeth_main.c
--- devel/drivers/s390/net/qeth_main.c~s390-use-klist-in-qeth-driver
2005-07-28 19:20:53.0 -0700
+++ devel-akpm/drivers/s390/net/qeth_main.c 2005-07-28 19:20:53.0
-0700
@@ -8120,20 +8120,22 @@ static struct notifier_block qeth_ip6_no
#endif
static int
-qeth_reboot_event(struct notifier_block *this, unsigned long event, void *ptr)
+__qeth_reboot_event_card(struct device *dev, void *data)
{
-
- struct device *entry;
struct qeth_card *card;
- down_read(_ccwgroup_driver.driver.bus->subsys.rwsem);
- list_for_each_entry(entry, _ccwgroup_driver.driver.devices,
- driver_list) {
- card = (struct qeth_card *) entry->driver_data;
- qeth_clear_ip_list(card, 0, 0);
- qeth_qdio_clear_card(card, 0);
- }
- up_read(_ccwgroup_driver.driver.bus->subsys.rwsem);
+ card = (struct qeth_card *) dev->driver_data;
+ qeth_clear_ip_list(card, 0, 0);
+ qeth_qdio_clear_card(card, 0);
+ return 0;
+}
+
+static int
+qeth_reboot_event(struct notifier_block *this, unsigned long event, void *ptr)
+{
+
+ driver_for_each_device(_ccwgroup_driver.driver, NULL, NULL,
+ __qeth_reboot_event_card);
return NOTIFY_DONE;
}
diff -puN drivers/s390/net/qeth_proc.c~s390-use-klist-in-qeth-driver
drivers/s390/net/qeth_proc.c
--- devel/drivers/s390/net/qeth_proc.c~s390-use-klist-in-qeth-driver
2005-07-28 19:20:53.0 -0700
+++ devel-akpm/drivers/s390/net/qeth_proc.c 2005-07-28 19:20:53.0
-0700
@@ -27,23 +27,33 @@ const char *VERSION_QETH_PROC_C = "$Revi
#define QETH_PROCFILE_NAME "qeth"
static struct proc_dir_entry *qeth_procfile;
+static int
+qeth_procfile_seq_match(struct device *dev, void *data)
+{
+ return 1;
+}
+
static void *
qeth_procfile_seq_start(struct seq_file *s, loff_t *offset)
{
- struct list_head *next_card = NULL;
- int i = 0;
+ struct device *dev;
+ loff_t nr;
down_read(_ccwgroup_driver.driver.bus->subsys.rwsem);
- if (*offset == 0)
+ nr = *offset;
+ if (nr == 0)
return SEQ_START_TOKEN;
- /* get card at pos *offset */
- list_for_each(next_card, _ccwgroup_driver.driver.devices)
- if (++i == *offset)
- return next_card;
+ dev = driver_find_device(_ccwgroup_driver.driver, NULL,
+NULL, qeth_procfile_seq_match);
- return NULL;
+ /* get card at pos *offset */
+ nr = *offset;
+ while (nr-- > 1 && dev)
+ dev = driver_find_device(_ccwgroup_driver.driver, dev,
+NULL, qeth_procfile_seq_match);
+ return (void *) dev;
}
static void
@@ -55,23 +65,21 @@ qeth_procfile_seq_stop(struct seq_file *
static void *
qeth_procfile_seq_next(struct seq_file *s, void *it, loff_t *offset)
{
- struct list_head *next_card = NULL;
- struct list_head *current_card;
+ struct device *prev, *next;
if (it == SEQ_START_TOKEN) {
- next_card = qeth_ccwgroup_driver.driver.devices.next;
- if (next_card->next == next_card) /* list empty */
- return NULL;
- (*offset)++;
- } else {
- current_card = (struct list_head *)it;
- if (current_card->next == _ccwgroup_driver.driver.devices)
- return NULL; /* end of list reached */
- next_card = current_card->next;
- (*offset)++;
+ next = driver_find_device(_ccwgroup_driver.driver,
+ NULL, NULL, qeth_procfile_seq_match);
+ if (next)
+ (*offset)++;
+ return (void *) next;
}
-
- return next_card;
+ prev =
[2.6 patch] arch/cris/Kconfig.debug: use lib/Kconfig.debug
This patch converts arch/cris/Kconfig.debug to using lib/Kconfig.debug. This should fix a compile error in 2.6.13-rc4 caused by a missing CONFIG_LOG_BUF_SHIFT definition. While I was editing this file, I also converted some spaces to tabs. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 31 Jul 2005 arch/cris/Kconfig.debug | 31 ++- 1 files changed, 10 insertions(+), 21 deletions(-) --- linux-2.6.13-rc4-mm1/arch/cris/Kconfig.debug.old2005-07-31 18:29:15.0 +0200 +++ linux-2.6.13-rc4-mm1/arch/cris/Kconfig.debug2005-07-31 18:32:15.0 +0200 @@ -5,10 +5,13 @@ bool "Kernel profiling support" config SYSTEM_PROFILER -bool "System profiling support" + bool "System profiling support" + +source "lib/Kconfig.debug" config ETRAX_KGDB bool "Use kernel GDB debugger" + depends on DEBUG_KERNEL ---help--- The CRIS version of gdb can be used to remotely debug a running Linux kernel via the serial debug port. Provided you have gdb-cris @@ -22,25 +25,11 @@ this option is turned on! -config DEBUG_INFO -bool "Compile the kernel with debug info" -help - If you say Y here the resulting kernel image will include - debugging info resulting in a larger kernel image. - Say Y here only if you plan to use gdb to debug the kernel. - If you don't debug the kernel, you can say N. - -config FRAME_POINTER -bool "Compile the kernel with frame pointers" -help - If you say Y here the resulting kernel image will be slightly larger - and slower, but it will give very useful debugging information. - If you don't debug the kernel, you can say N, but we may not be able - to solve problems without frame pointers. - config DEBUG_NMI_OOPS - bool "NMI causes oops printout" - help - If the system locks up without any debug information you can say Y - here to make it possible to dump an OOPS with an external NMI. + bool "NMI causes oops printout" + depends on DEBUG_KERNEL + help + If the system locks up without any debug information you can say Y + here to make it possible to dump an OOPS with an external NMI. + endmenu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] arch/sh64/Kconfig: doesn't need it's own LOG_BUF_SHIFT
The LOG_BUF_SHIFT from lib/Kconfig.debug is sufficient. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 31 Jul 2005 --- linux-2.6.13-rc4-mm1/arch/sh64/Kconfig.old 2005-07-31 18:24:19.0 +0200 +++ linux-2.6.13-rc4-mm1/arch/sh64/Kconfig 2005-07-31 18:24:26.0 +0200 @@ -29,10 +29,6 @@ bool default y -config LOG_BUF_SHIFT - int - default 14 - config RWSEM_XCHGADD_ALGORITHM bool - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: synchronize_rcu vs. rcu_barrier
What's the difference between synchronize_rcu() and rcu_barrier() (new function used only by reiser4 code)? From the scant documentation it seems like they do the same thing. I'm now happily running 2.6.13-rc4-rt-v0.7.52-14-reiser4 which I compiled by adding #define rcu_barrier synchronize_rcu so there must not be that much difference =) (at least on UP, that is). Keenan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote: > On Sun, 7 Aug 2005, Kyle Moffett wrote: > > On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: > > > > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb > > > though ... Can you try something like wrapper radeon_write_mode() with > > > preempt_disable()/preempt_enable() and tell me if it makes a > > > difference ? > > Did not help. The values used to initialize the mode seem to be wrong. > Copying the aty directory from 2.6.12 did not help, too. I don't see how PREEMPT could have any impact there unless you are experiencing memory corruption... or one of those panels that have so subtle timing issues that they sometimes don't sync depending on how many flies you have in your room Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Moving... please wait
On Sun, Aug 07, 2005 at 01:51:52PM -0700, Ravinandan Arakali wrote: > Jeff, > The entire set of patches have been resent and an additional > patch13 to address earlier comments. > Pls confirm if these patches apply correctly. I'm in the process of moving to a new house, and getting a new computer lab set up. I have email and can ACK any critical patches, but everything else must wait for 2.6.14 to open (which fits nicely into the 2.6 release cycle). Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc4: yenta_socket and swsusp
Andrew Morton wrote: > OK so we have one solid regression there. Are the other problems also new > since 2.6.11? > > Could you please retest 2.6.13-rc6 when it's out and if problems remain, > raise a bugzilla.kernel.org entry so we can keep track of the problem? > Thanks. After retesting with 2.6.13-rc6 quite some of the problems are gone. There are, however, still problems: 1. It is necessary to do the following or suspend will hang: cardctl eject killproc cardmgr remove all pcmcia modules In 2.6.11 it was sufficient to call 'cardctl eject'. I'll create a bug report. 2. The attached script can produce all sorts of pcmcia related problems if it is modified where stated - the attached version seems to work without problems if not modified. Do you want a bug report filed for this, too? -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] pcmcia.sh Description: Bourne shell script
Re: 2.6.13-rc4-mm1: iptables DROP crashes the computer
On 07/08/05, Patrick McHardy <[EMAIL PROTECTED]> wrote: > Could be related to the refcnt underflow with conntrack event > notifications enabled. If you have CONFIG_IP_NF_CONNTRACK_EVENTS > enabled please try this patch. > I can confirm that that patch solved my problems, thank you :) -- Mvh / Best regards Espen Fjellvær Olsen [EMAIL PROTECTED] Norway - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: assertion (cnt <= tp->packets_out) failed
On Sun, Aug 07, 2005 at 03:25:55PM +0200, John B?ckstrand wrote:
>
> [148475.651000] [ cut here ]
> [148475.651050] kernel BUG at net/ipv4/tcp_output.c:918!
Yes, as Andrew said, this bug should be fixed in the latest git tree.
So please test with that plus the debugging patch to see if you can
reproduce the assertion again.
Thanks,
--
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/
Re: Lost Ticks on x86_64
On Sun, Aug 07, 2005 at 02:51:19PM -0400, Lee Revell wrote: > > It's most likely bad SMM code in the BIOS that blocks the CPU too long > > and is triggered in idle. You can verify that by using idle=poll > > (not recommended for production, just for testing) and see if it goes away. > > > > WTF, since when do *desktops* use SMM? Are you telling me that we have > to worry about these stupid ACPI/SMM hardware bugs on the desktop too? SMM is how BIOSes do legacy support (which stops at OS-handover). It's also how some BIOSes do ECC reporting and logging. We just do pci tweaks to turn it off in the OS. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops with 2.6.13-rc5 on webserver with raid
On Fri, Aug 05, 2005 at 11:52:15AM +0200 Martin Braun wrote: > Hi, > > I've been trying to upgrade kernel to 2.6.13-rc5. The server boots > normally w/o errors, but after while (from 5 minutes up to 2 hours) the > Kernel hangs (no keyboard input possible). As I am a newbie I cannot > figure out who will be concerned with this error. Please don't run ksymoops on 2.6 kernels, it makes the output look weird and isn't necessary anymore. > > >>EIP; c0324afd<= > Should be fixed in 2.6.13-rc6, if problem persists please report back. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sluggish/very slow usb mouse on hp nx6110 notebook => acpi problem
On Fri, Aug 05, 2005 at 08:56:51PM +0200 JG wrote: > hm, i currently have "acpi=off noacpi noapic reboot=b" as kernel > parameter. > > if i remove the acpi stuff and enable acpi, the usb mouse works fine.. > but after some time (5-10min) the kacpid process goes havoc and eats > all cpu and the whole system is unresponsive- that's the reason i added > those acpi=off parameters the first time when installing gentoo.. > > i tested with gentoo-2.6.12-r7 and vanilla-2.6.13rc5 > Indicates a bug in kacpid or similar. Could you make sure you compile in "Magic SysRq key" under "Kernel Hacking" and boot the vanilla-2.6.13-rc6 (some recent acpi changes have gone in) and then wait for kacpid to go nuts and do Alt+Sysrq+t 4 times and then run 'dmesg -s 10 > logfile' and send logfile over here so that we can see what kacpid is up to. If the box becomes so unresponsive you can't extract the log information it would be good if you could use either network console Documentation/networking/netconsole.txt or serial console at Documentation/serial-console.txt, both require an extra computer though... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
În data de Du, 07-08-2005 la 11:47 -0700, Linus Torvalds a scris: > Luming Yu: > [ACPI] revert Embedded Controller to polling-mode by default (ala 2.6.12) > [ACPI] CONFIG_ACPI_HOTKEY is now "n" by default IMHO you really need then to make acpi_specific_hotkey the default or at least mention it in the release notes or you'll have tons of people screaming that the specific module does not work anymore. I found out about it after my toshiba_acpi module stopped working and I noticed a small change in the development acpi tree documentation mentioning acpi_specific_hotkey ... -- Cioby - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockups with netconsole on e1000 on media insertion
Steven Rostedt wrote: I don't have the card, so I can't test it. But if this works (after removing the previous patch) then this is the better solution. I can confirm that this alone does not work for the simple unplug/re-plug cycle I described, it still locks up hard. Tried this alone on -rc6. --- John Bäckstrand - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc5-mm1: oops when starting nscd on AMD64
On Sunday, 7 of August 2005 19:23, Andrew Morton wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > I get the following Oops after trying to start nscd from YaST on an
> > Athlon64-based box
> > (compiled with CONFIG_DEBUG_SPINLOCK=y):
> >
> > Unable to handle kernel NULL pointer dereference at 0008 RIP:
> > {kmem_cache_alloc+232}
> > PGD 1501a067 PUD 1501b067 PMD 0
> > Oops: [1] PREEMPT
> > CPU 0
> > Modules linked in: raw af_key usbserial thermal processor fan button
> > battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97t
> > Pid: 6570, comm: nscd Not tainted 2.6.13-rc5-mm1
> > RIP: 0010:[] {kmem_cache_alloc+232}
> > RSP: 0018:81001506de88 EFLAGS: 00010202
> > RAX: RBX: 8010eb3e RCX:
> > RDX: RSI: 8100292bdd68 RDI: 810001c3f6c0
> > RBP: 81001506deb8 R08: R09: 8100292bdd70
> > R10: 0006 R11: R12: 810001c3f6c0
> > R13: 8100292bdd68 R14: 80d0 R15: 801abe5c
> > FS: 2b11cb00() GS:804f2840()
> > knlGS:56abc320
> > CS: 0010 DS: ES: CR0: 8005003b
> > CR2: 0008 CR3: 15019000 CR4: 06e0
> > Process nscd (pid: 6570, threadinfo 81001506c000, task
> > 81001506b250)
> > Stack: 0246 81001569b5a0 8100155fe980
> > fff4 000a 81001506df78 801abe5c
> > 40a05fff 81001569b5a0
> > Call Trace:{sys_epoll_create+604}
> > {add_preempt_count+105}
> > {system_call+126}
> > BUG: spinlock trylock failure on UP on CPU#0, nscd/6570
> > lock: 803bae80, .magic: dead4ead, .owner: nscd/6570, .owner_cpu: 0
> >
> > Call Trace:{add_preempt_count+105}
> > {spin_bug+211}
> > {show_trace+571}
> > {_raw_spin_trylock+62}
> > {_spin_trylock+30}
> > {oops_begin+17}
> > {do_page_fault+1722}
> > {vprintk+830}
> > {vprintk+830}
> > {kallsyms_lookup+246}
> > {error_exit+0} {show_trace+571}
> > {show_trace+567}
> > {show_stack+216}
> > {show_registers+135} {__die+142}
> > {do_page_fault+1832}
> > {vsnprintf+1393}
> > {sys_epoll_create+604}
> > {error_exit+0}
> > {sys_epoll_create+604}
> > {system_call+126}
> > {kmem_cache_alloc+232}
> > {kmem_cache_alloc+216}
> > {sys_epoll_create+604}
> > {add_preempt_count+105}
> > {system_call+126}
> > ---
> > | preempt count: 0002 ]
> > | 2 level deep critical section nesting:
> >
> > .. [] _spin_trylock+0x16/0x60
> > .[] .. ( <= oops_begin+0x11/0x60)
> > .. [] _spin_trylock+0x16/0x60
> > .[] .. ( <= oops_begin+0x11/0x60)
>
> I don't think it was supposed to do that.
>
> Quite possibly it's something to do with the new debugging code - could you
> please take a copy of the offending config, send it over and then try
> removing debug options, see if the crash goes away? CONFIG_DEBUG_PREEMPT
> would be the first to try..
The (offending) .config is attached and here's what happens without
CONFIG_DEBUG_PREEMPT
(the other debug options being unchanged):
Bootdata ok (command line is root=/dev/hdc6 vga=792 selinux=0 noapic
resume=/dev/hdc3 console=ttyS0,57600 console=tty0 debug)
Linux version 2.6.13-rc5-mm1 ([EMAIL PROTECTED]) (gcc version 3.3.5 20050117
(prerelease) (SUSE Linux)) #2 PREEMPT Sun Aug 7 21:10:38 CEST 2005
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000e - 0010 (reserved)
BIOS-e820: 0010 - 2ff4 (usable)
BIOS-e820: 2ff4 - 2ff5 (ACPI data)
BIOS-e820: 2ff5 - 3000 (ACPI NVS)
BIOS-e820: fec0 - fec01000 (reserved)
BIOS-e820: fee0 - fee01000 (reserved)
ACPI: RSDP (v000 ACPIAM) @ 0x000f76e0
ACPI: RSDT (v001 A M I OEMRSDT 0x05000425 MSFT 0x0097) @
0x2ff4
ACPI: FADT (v001 A M I OEMFACP 0x05000425 MSFT 0x0097) @
0x2ff40200
ACPI: OEMB (v001 A M I OEMBIOS 0x05000425 MSFT 0x0097) @
0x2ff50040
>>> ERROR: Invalid checksum
ACPI: DSDT (v001 L5DK8 L5DK8014 0x0014 INTL 0x02002026) @
0x
On node 0 totalpages: 196416
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 192320 pages, LIFO batch:31
HighMem zone: 0 pages, LIFO batch:1
Nvidia board detected. Ignoring ACPI timer override.
ACPI: PM-Timer IO Port: 0x4008
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: ASUSTeK <6>Product ID: L5D <6>APIC at: 0xFEE0
Processor #0 15:4 APIC version 16
I/O APIC #1 Version 17
Re: FYI: device_suspend(...) in kernel_power_off().
Hi! > >> There as been a fair amount of consensus that calling > >> device_suspend(...) in the reboot path was inappropriate now, because > >> the device suspend code was too immature. With this latest > >> piece of evidence it seems to me that introducing device_suspend(...) > >> in kernel_power_off, kernel_halt, kernel_reboot, or kernel_kexec > >> can never be appropriate. > > > > Code is not ready now => it can never be fixed? Thats quite a strange > > conclusion to make. > > It seems there is an fundamental incompatibility with ACPI power off. > As best as I can tell the normal case of device_suspend(PMSG_SUSPEND) > works reasonably well in 2.6.x. Powerdown is going to have the same problems as the powerdown at the end of suspend-to-disk. Can you ask people reporting broken shutdown to try suspend-to-disk? > >From what I can tell there are some fairly fundamental semantic > differences, on that code path. The most peculiar problem I tracked > is someone had a machine that would go into power off state and then > wake right back up because of the device_suspend(PMSG_SUSPEND) > change. So something is wrong with ACPI wakeup GPEs. It would hurt in suspend-to-disk case, too. > I won't call it impossible to resolve the problems, but the people Good. > So yes without a darn good argument as to why it should work. I will > go with the experimental evidence that it fails miserably and > trivially because of semantic incompatibility and can therefore > never be fixed. I do not think any "semantic" issues exist. We need to pass detailed info down to the drivers that care, and we need to fix all the bugs in the drivers. That should be pretty much it. 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] driver core: Add the ability to unbind drivers to devices from userspace
Hi! > > > It is not a work around. These are text attributes meant for human > > > use. Humans have a hard time cleaning up things they can't see. And > > > the failure mode for this is awful, your attribute won't set but > > > everything on the screen looks fine. > > > > Kernel is not a place to be user friendly. Or do you propose stripping > > whitespace > > for open(), too? File called "foo.txt" certainly *is* going to be > > confusing, but it should be allowed at kernel level. > > open is not made for human use, it is used by programs and only > indirectly by humans. sysfs variables are used by directly humans. Both are kernel interfaces; I can use open() by hand just fine... > > Now... echo foo > /sys/var does not properly report errors. Thats bad, but > > it needs to > > be fixed in bash. > > It is going to take a lot more code to return an error that a > parameter didn't match because of extra white space that it would take > to simply remove the whitespace. I believe we do correctly report errors in write() calls already. Bash not reporting them to the user is different problem. 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: Fw: Re: Elitegroup K7S5A + usb_storage problem
On Sun, 7 Aug 2005 22:47:40 +0200, Martin Maurer <[EMAIL PROTECTED]> wrote: > > Just out of curiosity, if you plug the player into a Windows system > > without installing any special drivers first, will Windows be able to read > > and write files okay? If it can, a USB packet trace may give Pete a clue > > as to where to look. > as far as i recall i didnt install any special drivers for my win 2k and win > xp systems. (i got this mp3 player quite a while now...) > How would I do such an packet trace ? I have never run Snoopy on Windows myself and I did not want to subject you to it. Let's try my delay patch first. If that fails, I guess we have to get instructions from someone who knows how to run Snoopy. Maybe Windows issues some cache synchronization command when it commits FAT. Then the packet trace should show it. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Alsa-devel] Re: any update on the pcmcia bug blocking Audigy2 notebook sound card driver development
Thanks, Lee. That's the bug I'm referring to. It would be great if laptop users can enjoy the higher sound quality the Audigy2 pcmcia sound card offers, which is way better than the builtin onboard sound. Raymond On 8/7/05, Lee Revell <[EMAIL PROTECTED]> wrote: > On Sun, 2005-08-07 at 10:43 -0700, Andrew Morton wrote: > > Raymond Lai <[EMAIL PROTECTED]> wrote: > > > > > > Hi all, > > > > > > I remember there's a kernel pcmcia bug preventing the development for > > > the Audigy2 pcmcia notebook sound card driver. > > > > > > See > > > http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Creative_Labs#matrix > > > > > > Is there any new updates on the situation? Has the bug been fixed? or > > > anyone working on it? > > > > > > > Is it related to http://bugzilla.kernel.org/show_bug.cgi?id=4788 ? > > No, that was a known issue that is resolved in 2.6.13-rc*. This is the > bug he's referring to: > > http://lkml.org/lkml/2005/7/11/265 > > Looks like James never followed up, probably due to OLS. > > 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: Linux-2.6.13-rc6: aic7xxx testers please..
On Sun, 2005-08-07 at 13:50 -0700, Linus Torvalds wrote: > > On Sun, 7 Aug 2005, Lee Revell wrote: > > > > It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer > > an option). But now I get this ominous warning when I compile > > ndiswrapper: > > It's still there, and it (still) depends on DEBUG_KERNEL. Nothing should > have changed afaik.. OK, thanks, sorry for the noise. I remember there was talk recently of 4K stacks for everyone and was afraid it had already happened. 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: Fw: Elitegroup K7S5A + usb_storage problem
> when i delete the files which are on the stick and do an umount/mount cycle, > the files are there again. >[... other mail ...] > I did the usbmon thing (hopefully correctly). Attached is the output. Yes, that was perfect, thanks a lot. Unfortunately, I do not see a lot of interesting things. The last write before the disconnect is a FAT update: c31650b8 1617078003 S Bo:006:01 -115 31 = 55534243 c600 0002 0a2a 3001 00 c31650b8 1617078987 C Bo:006:01 0 31 > c31650b8 1617078997 S Bo:006:01 -115 512 = f8ff c31650b8 1617080988 C Bo:006:01 0 512 > c31650b8 1617080998 S Bi:006:02 -115 13 < c31650b8 1617084987 C Bi:006:02 0 13 = 55534253 c600 00 Only one cluster was taken, when compared with the FAT that was read. Everything seems to be in order. But the next trace (after replug - see the device number changing from 6 to 7) shows FAT with old contents being read (same block number 0x30): > cd6960b8 1874976301 S Bo:007:01 -115 31 = 55534243 0b00 0002 8a28 > 3001 00 > cd6960b8 1874977274 C Bo:007:01 0 31 > > cd6960b8 1874977288 S Bi:007:02 -115 512 < > cd6960b8 1874979271 C Bi:007:02 0 512 = f8ff > > cd6960b8 1874979282 S Bi:007:02 -115 13 < > cd6960b8 1874981271 C Bi:007:02 0 13 = 55534253 0b00 00 So, the device replies that writes were successful, but does not actually commit them to the stable storage. I suspect that this device may require some delays. I seem to recall that we added delayes to usb-storage when we worked with Genesys Logic. But ub contains no delays. How about this: --- linux-2.6.13-rc4/drivers/block/ub.c 2005-07-29 19:51:00.0 -0700 +++ linux-2.6.13-rc4-lem/drivers/block/ub.c 2005-08-07 13:48:11.0 -0700 @@ -1209,6 +1279,8 @@ return; } + udelay(125);// XXX for Martin Maurer <[EMAIL PROTECTED]> + UB_INIT_COMPLETION(sc->work_done); if (cmd->dir == UB_DIR_READ) Please try this patchlet and let us know how it went. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Sun, 7 Aug 2005, Lee Revell wrote: > > It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer > an option). But now I get this ominous warning when I compile > ndiswrapper: It's still there, and it (still) depends on DEBUG_KERNEL. Nothing should have changed afaik.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Re: Elitegroup K7S5A + usb_storage problem
On Sunday, 7. August 2005 20:08, Alan Stern wrote: > On Sun, 7 Aug 2005 [EMAIL PROTECTED] wrote: > > Hi Alan, > > > > no. the stick doesn't have a write protection switch. > > Once when i tried to copy a file to the mp3 player i got a new file there > > on remount, but it consisted of incorrect data. (so writing seemed to be > > possible and just went wrong) (in that case the fat seemed to be damaged > > after i had tried this, so that windows wasn't able to read it correctly > > any more. > > (formatting from the mp3 players menu helped) > > Well, perhaps the device isn't consistently writing data to the > correct locations. > > > greetings > > Martin > > > > PS: just as an info - i sent a usbmon trace to Pete Zaitcev today, should > > I send it to you too? > > Pete is quite as competent at solving this kind of problem as I am. And > he knows the ub driver much better, so I'm happy to bow out and let him > worry about it! :-) > > Just out of curiosity, if you plug the player into a Windows system > without installing any special drivers first, will Windows be able to read > and write files okay? If it can, a USB packet trace may give Pete a clue > as to where to look. as far as i recall i didnt install any special drivers for my win 2k and win xp systems. (i got this mp3 player quite a while now...) How would I do such an packet trace ? > > Alan Stern > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ pgpEicsCRSKbU.pgp Description: PGP signature
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Sun, 2005-08-07 at 11:47 -0700, Linus Torvalds wrote: > James and gang found the aic7xxx slowdown that happened after 2.6.12, and > we'd like to get particular testing that it's fixed, so if you have a > relevant machine, please do test this. > > There are other fixes too, a number of them reverting (at least for now) > patches that people had problems with. In general, anybody who has > reported regressions since 2.6.12, please re-test with -rc6 and report > back (even if, or perhaps _particularly_ if, no change to the regression). It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer an option). But now I get this ominous warning when I compile ndiswrapper: *** WARNING: Kernel seems to have 4K size stack option (CONFIG_4KSTACKS) removed; many Windows drivers will need at least 8K size stacks. You should read wiki about 4K size stack issue. Don't complain about crashes until you resolve this As ndiswrapper seems to be the only option for many wireless chipsets, this certainly looks like it will lead to regressions. Why was this option removed? It's pretty clear that lots of out of tree drivers still require it. 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/
synchronize_rcu vs. rcu_barrier
What's the difference between synchronize_rcu() and rcu_barrier() (new function used only by reiser4 code)? From the scant documentation it seems like they do the same thing. Keenan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Linus Torvalds wrote: > In general, anybody who has reported regressions since 2.6.12, please > re-test with -rc6 and report back > ... > Herbert Xu: > tcp: fix TSO cwnd caching bug The tcp_output panic bug seems to be fixed. I'm referring to: http://lkml.org/lkml/2005/8/7/63 -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] driver core: Add the ability to unbind drivers to devices from userspace
On 8/7/05, Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > > > > Could you tell me why you don't just fail the operation if malformed > > > > > input is supplied? > > > > > > > > Leading/trailing white space should be allowed. For example echo > > > > appends '\n' unless you know to use -n. It is easier to fix the kernel > > > > than to teach everyone to use -n. > > > > > > Please, NO! echo -n is the right thing to do, and users will eventually > > > learn. > > > We are not going to add such workarounds all over the kernel... > > > > It is not a work around. These are text attributes meant for human > > use. Humans have a hard time cleaning up things they can't see. And > > the failure mode for this is awful, your attribute won't set but > > everything on the screen looks fine. > > Kernel is not a place to be user friendly. Or do you propose stripping > whitespace > for open(), too? File called "foo.txt" certainly *is* going to be > confusing, but it should be allowed at kernel level. open is not made for human use, it is used by programs and only indirectly by humans. sysfs variables are used by directly humans. > > Now... echo foo > /sys/var does not properly report errors. Thats bad, but it > needs to > be fixed in bash. It is going to take a lot more code to return an error that a parameter didn't match because of extra white space that it would take to simply remove the whitespace. > -- > 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms > > -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lost Ticks on x86_64
On Sun, Aug 07, 2005 at 02:46:50PM -0400, Erick Turnquist wrote: > > Some BIOSes do not lock SMM, and you *could* turn it off at the chipset > > level. > > I don't see anything about SMM in my BIOS configuration even with the > advanced options enabled... Turning it off at the chipset level sounds > like a hardware hack - is it? No, it's usually just a PCI register you can change. Depends on your chipset, though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.6.13-rc5-git-current (0d317fb72fe3cf0f611608cf3a3015bbe6cd2a66)
> Unable to handle kernel paging request at virtual address 6b6b6b6b
> printing eip:
> c0188d15
> *pde =
> Oops: [#1]
> PREEMPT
> CPU:0
> EIP:0060:[inotify_inode_queue_event+85/336]Not tainted VLI
> EFLAGS: 00010206 (2.6.13-rc5-g0d317fb7)
> EIP is at inotify_inode_queue_event+0x55/0x150
> eax: 6b6b6b6b ebx: 6b6b6b63 ecx: edx: 0066
> esi: c3effe34 edi: ce8c76ac ebp: d4bb864c esp: d8655eb0
> ds: 007b es: 007b ss: 0068
> Process nfsd (pid: 3750, threadinfo=d8654000 task=d6155020)
> Stack: 0286 0286 0400 d4bb8760 d4bb8768
> c3effe34
>ce8c76ac d4bb864c c0170626 c3effe34 d6608ad4 db74b17c
> c3effe34
>e0cfe9a4 0013 e0d01b34 c0dd91b4 ce8c76ac c000 d66092dc
> d66093c4
> Call Trace:
> [vfs_unlink+358/560] vfs_unlink+0x166/0x230
> [pg0+544348580/1067586560] nfsd_unlink+0x104/0x230 [nfsd]
> [pg0+544361268/1067586560] nfsd_cache_lookup+0x1c4/0x3c0 [nfsd]
> [pg0+544371728/1067586560] nfsd3_proc_remove+0x80/0xc0 [nfsd]
> [pg0+544381018/1067586560] nfs3svc_decode_diropargs+0x8a/0x100 [nfsd]
> [pg0+544380880/1067586560] nfs3svc_decode_diropargs+0x0/0x100 [nfsd]
> [pg0+544321698/1067586560] nfsd_dispatch+0x82/0x1f0 [nfsd]
> [svc_authenticate+112/336] svc_authenticate+0x70/0x150
> [svc_process+960/1648] svc_process+0x3c0/0x670
> [pg0+544323105/1067586560] nfsd+0x1a1/0x350 [nfsd]
> [ret_from_fork+6/20] ret_from_fork+0x6/0x14
> [pg0+544322688/1067586560] nfsd+0x0/0x350 [nfsd]
> [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10
(akpm: a fix for this needs to go into 2.6.13, inotify + nfs
trivially oopses otherwise, even if inotify isn't actively used)
It looks like the following sequence is done in the wrong order.
When vfs_unlink() is called from sys_unlink() it has taken a ref
on the inode and sys_unlink() does the last iput() but when called
from other callsites vfs_unlink() might do the last iput() and
free inode, so inotify_inode_queue_event() will receive an already
freed object and dereference an already freed object.
Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
Index: mm/fs/namei.c
===
--- mm.orig/fs/namei.c 2005-08-07 12:06:16.0 +0200
+++ mm/fs/namei.c 2005-08-07 18:17:20.0 +0200
@@ -1869,8 +1869,8 @@
/* We don't d_delete() NFS sillyrenamed files--they still exist. */
if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
struct inode *inode = dentry->d_inode;
- d_delete(dentry);
fsnotify_unlink(dentry, inode, dir);
+ d_delete(dentry);
}
return 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: Lost Ticks on x86_64
On Sun, 7 Aug 2005, Lee Revell wrote: > > It's most likely bad SMM code in the BIOS that blocks the CPU too long > > and is triggered in idle. You can verify that by using idle=poll > > (not recommended for production, just for testing) and see if it goes away. > > > > WTF, since when do *desktops* use SMM? Are you telling me that we have > to worry about these stupid ACPI/SMM hardware bugs on the desktop too? It's a general platform thing and has been around for ages now... Intel's ICH* definitely use it for example and those are on a lot of desktop systems. For example, turning on "Legacy USB support" will generate periodic SMIs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wireless support
On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote: > Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS) > supported? > Wow, Google has really declined in quality. I got zero hits for "Linksys WUSB 54G linux". Then I found this page on my own. (from http://ndiswrapper.sourceforge.net/mediawiki/index.php/List) Card: Linksys #[WUSB54G], 802.11b/g, USB 2.0 -- [link here|List#WUSB54G] * Chipset: Prism54 * usbid: 5041:2234 * Driver: Linksys Windows XP driver http://www.linksys.com/download/default.asp * Other: Works smoothly, of course ;) - this is the device the USB extension was originally developed for. WEP is running, WPA is supported using wpa_supplicant 0.2.5. No problems with both 1.1 and 2.0 host controllers. As with many other USB devices, no success with 2.4 kernels so far. Try to use 2.6.7 or better. There is a native driver for Prism54 that is working on USB support. View its status at Prism54.org Sorry for the WOB. And if anyone from Google is reading, WTF? 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: FYI: device_suspend(...) in kernel_power_off().
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > >> There as been a fair amount of consensus that calling >> device_suspend(...) in the reboot path was inappropriate now, because >> the device suspend code was too immature. With this latest >> piece of evidence it seems to me that introducing device_suspend(...) >> in kernel_power_off, kernel_halt, kernel_reboot, or kernel_kexec >> can never be appropriate. > > Code is not ready now => it can never be fixed? Thats quite a strange > conclusion to make. It seems there is an fundamental incompatibility with ACPI power off. As best as I can tell the normal case of device_suspend(PMSG_SUSPEND) works reasonably well in 2.6.x. >From what I can tell there are some fairly fundamental semantic differences, on that code path. The most peculiar problem I tracked is someone had a machine that would go into power off state and then wake right back up because of the device_suspend(PMSG_SUSPEND) change. If acpi power off doesn't expect the hardware to be suspended I don't see how you can make device_suspend(PMSG_SUSPEND) a default in 2.6.x. I won't call it impossible to resolve the problems, but the people doing it must be extremely sensitive to the subtle semantic differences that exist and the burden of proof for showing things work better need to be extremely high. And the developer who reintroduces it gets to own all of the reboot/halt/power off problems in the stable tree when it gets merged. Pavel the fact that you did not articulate a possibility that your change could have caused most of the problems that were seen with it is what scares me the most. The fairly trivial and obvious problems were not addressed when the patch was merged much less the subtle ones. Your initial patch did not even touch all of the code paths necessary to achieve what it was trying to do. So yes without a darn good argument as to why it should work. I will go with the experimental evidence that it fails miserably and trivially because of semantic incompatibility and can therefore never be fixed. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] fix PHYCONTROL=n compilation
On Sun, Aug 07, 2005 at 11:51:23AM -0700, Avuton Olrich wrote:
> On 8/7/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc5/2.6.13-rc5-mm1/
>
> I probably don't need/want phy stuff anyhow, but when I tried it:
>
> Problem:
> drivers/built-in.o: In function `phy_start_machine':
> : undefined reference to `phy_timer'
> drivers/built-in.o: In function `phy_stop_machine':
> : undefined reference to `phy_stop_interrupts'
> make: *** [.tmp_vmlinux1] Error 1
>...
Thanks for this report, it seems noone aactually tried whether
CONFIG_PHYCONTROL=n compiles...
A possible patch is below.
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/phy/phy.c | 141 +-
1 files changed, 71 insertions(+), 70 deletions(-)
--- linux-2.6.13-rc5-mm1/drivers/net/phy/phy.c.old 2005-08-07
21:18:29.0 +0200
+++ linux-2.6.13-rc5-mm1/drivers/net/phy/phy.c 2005-08-07 21:29:33.0
+0200
@@ -39,7 +39,6 @@
#include
#include
-static void phy_change(void *data);
static void phy_timer(unsigned long data);
/* Convenience function to print out the current phy status
@@ -273,31 +272,6 @@
}
EXPORT_SYMBOL(phy_sanitize_settings);
-/* phy_force_reduction
- *
- * description: Reduces the speed/duplex settings by
- * one notch. The order is so:
- * 1000/FULL, 1000/HALF, 100/FULL, 100/HALF,
- * 10/FULL, 10/HALF. The function bottoms out at 10/HALF.
- */
-static void phy_force_reduction(struct phy_device *phydev)
-{
- int idx;
-
- idx = phy_find_setting(phydev->speed, phydev->duplex);
-
- idx++;
-
- idx = phy_find_valid(idx, phydev->supported);
-
- phydev->speed = settings[idx].speed;
- phydev->duplex = settings[idx].duplex;
-
- pr_info("Trying %d/%s\n", phydev->speed,
- DUPLEX_FULL == phydev->duplex ?
- "FULL" : "HALF");
-}
-
/* phy_ethtool_sset:
* A generic ethtool sset function. Handles all the details
*
@@ -464,7 +438,6 @@
phydev->adjust_state = NULL;
}
-#ifdef CONFIG_PHYCONTROL
/* phy_error:
*
* Moves the PHY to the HALTED state in response to a read
@@ -479,6 +452,75 @@
spin_unlock(>lock);
}
+/* Disable the PHY interrupts from the PHY side */
+int phy_disable_interrupts(struct phy_device *phydev)
+{
+ int err;
+
+ /* Disable PHY interrupts */
+ err = phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED);
+
+ if (err)
+ goto phy_err;
+
+ /* Clear the interrupt */
+ err = phy_clear_interrupt(phydev);
+
+ if (err)
+ goto phy_err;
+
+ return 0;
+
+phy_err:
+ phy_error(phydev);
+
+ return err;
+}
+EXPORT_SYMBOL(phy_disable_interrupts);
+
+int phy_stop_interrupts(struct phy_device *phydev)
+{
+ int err;
+
+ err = phy_disable_interrupts(phydev);
+
+ if (err)
+ phy_error(phydev);
+
+ free_irq(phydev->irq, phydev);
+
+ return err;
+}
+EXPORT_SYMBOL(phy_stop_interrupts);
+
+/* phy_force_reduction
+ *
+ * description: Reduces the speed/duplex settings by
+ * one notch. The order is so:
+ * 1000/FULL, 1000/HALF, 100/FULL, 100/HALF,
+ * 10/FULL, 10/HALF. The function bottoms out at 10/HALF.
+ */
+static void phy_force_reduction(struct phy_device *phydev)
+{
+ int idx;
+
+ idx = phy_find_setting(phydev->speed, phydev->duplex);
+
+ idx++;
+
+ idx = phy_find_valid(idx, phydev->supported);
+
+ phydev->speed = settings[idx].speed;
+ phydev->duplex = settings[idx].duplex;
+
+ pr_info("Trying %d/%s\n", phydev->speed,
+ DUPLEX_FULL == phydev->duplex ?
+ "FULL" : "HALF");
+}
+
+#ifdef CONFIG_PHYCONTROL
+
+static void phy_change(void *data);
/* phy_interrupt
*
* description: When a PHY interrupt occurs, the handler disables
@@ -515,32 +557,6 @@
}
EXPORT_SYMBOL(phy_enable_interrupts);
-/* Disable the PHY interrupts from the PHY side */
-int phy_disable_interrupts(struct phy_device *phydev)
-{
- int err;
-
- /* Disable PHY interrupts */
- err = phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED);
-
- if (err)
- goto phy_err;
-
- /* Clear the interrupt */
- err = phy_clear_interrupt(phydev);
-
- if (err)
- goto phy_err;
-
- return 0;
-
-phy_err:
- phy_error(phydev);
-
- return err;
-}
-EXPORT_SYMBOL(phy_disable_interrupts);
-
/* phy_start_interrupts
*
* description: Request the interrupt for the given PHY. If
@@ -572,21 +588,6 @@
}
EXPORT_SYMBOL(phy_start_interrupts);
-int phy_stop_interrupts(struct phy_device *phydev)
-{
- int err;
-
- err = phy_disable_interrupts(phydev);
-
- if (err)
- phy_error(phydev);
-
- free_irq(phydev->irq, phydev);
-
- return err;
-}
Re: [PATCH 1/1] i386 Encapsulate copying of pgd entries
Hi!
> Since most hypervisors will likely provide a suspend/resume mechanism
> that is external to the guest, most of this is a moot point anyways.
Ok.
> But I wondered if you thought the pgd_clone() accessor would make this
> cleaner or if it is just most confusing:
>
> #ifdef CONFIG_SOFTWARE_SUSPEND
> /*
> * Swap suspend & friends need this for resume because things like the
> intel-agp
> * driver might have split up a kernel 4MB mapping.
> */
> char __nosavedata swsusp_pg_dir[PAGE_SIZE]
>__attribute__ ((aligned (PAGE_SIZE)));
>
> static inline void save_pg_dir(void)
> {
>memcpy(swsusp_pg_dir, swapper_pg_dir, PAGE_SIZE); <--- could be
> clone_pgd_range()
> }
Yep, clone_pgd_range would make sense here...
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/
Wireless support
Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS) supported? TIA, Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] i386 Encapsulate copying of pgd entries
Pavel Machek wrote:
Hi!
This helps complete the encapsulation of updates to page tables (or pages
about to become page tables) into accessor functions rather than using
memcpy() to duplicate them. This is both generally good for consistency
and also necessary for running in a hypervisor which requires explicit
updates to page table entries.
Hmm, I'm not sure if this kind of hypervisor can reasonably work with swsusp;
swsusp is just copying memory, it does not know which part of memory are page
tables.
Pavel
There are good and bad things about this. Everything with swap suspend
should be fine for the suspend portion of things; it is when resuming
back up that one must take care to call the hypervisor functions for
reloading control registers and updating page tables.
I'm not sure that Xen can cope with that scenario - it would have to go
into shadowed mode first, then after resume, go back from shadow mode
into direct page table mode. Otherwise, as you say, making swap suspend
aware of what pages are page tables would be quite difficult and
needlessly complicate the code.
Since most hypervisors will likely provide a suspend/resume mechanism
that is external to the guest, most of this is a moot point anyways.
But I wondered if you thought the pgd_clone() accessor would make this
cleaner or if it is just most confusing:
#ifdef CONFIG_SOFTWARE_SUSPEND
/*
* Swap suspend & friends need this for resume because things like the
intel-agp
* driver might have split up a kernel 4MB mapping.
*/
char __nosavedata swsusp_pg_dir[PAGE_SIZE]
__attribute__ ((aligned (PAGE_SIZE)));
static inline void save_pg_dir(void)
{
memcpy(swsusp_pg_dir, swapper_pg_dir, PAGE_SIZE); <--- could be
clone_pgd_range()
}
Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[WATCHDOG] i8xx_tco.c - patch to arm watchdog only when started (Kernel Bug 4251)
Hi Linus,
Please add the following patch/bugfix:
i8xx_tco.c v0.08: only "arm" the watchdog when the watchdog has been started.
(Kernel Bug 4251: system reset when battery is read and i8xx_tco driver loaded)
Greetings,
Wim.
diff -Nru a/drivers/char/watchdog/i8xx_tco.c b/drivers/char/watchdog/i8xx_tco.c
--- a/drivers/char/watchdog/i8xx_tco.c 2005-08-07 20:33:01 +02:00
+++ b/drivers/char/watchdog/i8xx_tco.c 2005-08-07 20:41:25 +02:00
@@ -1,5 +1,5 @@
/*
- * i8xx_tco 0.07: TCO timer driver for i8xx chipsets
+ * i8xx_tco: TCO timer driver for i8xx chipsets
*
* (c) Copyright 2000 kernel concepts <[EMAIL PROTECTED]>, All Rights
Reserved.
* http://www.kernelconcepts.de
@@ -63,6 +63,9 @@
* 20050128 Wim Van Sebroeck <[EMAIL PROTECTED]>
* 0.07 Added support for the ICH4-M, ICH6, ICH6R, ICH6-M, ICH6W and ICH6RW
* chipsets. Also added support for the "undocumented" ICH7 chipset.
+ * 20050807 Wim Van Sebroeck <[EMAIL PROTECTED]>
+ * 0.08 Make sure that the watchdog is only "armed" when started.
+ * (Kernel Bug 4251)
*/
/*
@@ -87,7 +90,7 @@
#include "i8xx_tco.h"
/* Module and version information */
-#define TCO_VERSION "0.07"
+#define TCO_VERSION "0.08"
#define TCO_MODULE_NAME "i8xx TCO timer"
#define TCO_DRIVER_NAME TCO_MODULE_NAME ", v" TCO_VERSION
#define PFX TCO_MODULE_NAME ": "
@@ -125,10 +128,18 @@
unsigned char val;
spin_lock(_lock);
+
+ /* disable chipset's NO_REBOOT bit */
+ pci_read_config_byte (i8xx_tco_pci, 0xd4, );
+ val &= 0xfd;
+ pci_write_config_byte (i8xx_tco_pci, 0xd4, val);
+
+ /* Bit 11: TCO Timer Halt -> 0 = The TCO timer is enabled to count */
val = inb (TCO1_CNT + 1);
val &= 0xf7;
outb (val, TCO1_CNT + 1);
val = inb (TCO1_CNT + 1);
+
spin_unlock(_lock);
if (val & 0x08)
@@ -138,13 +149,20 @@
static int tco_timer_stop (void)
{
- unsigned char val;
+ unsigned char val, val1;
spin_lock(_lock);
+ /* Bit 11: TCO Timer Halt -> 1 = The TCO timer is disabled */
val = inb (TCO1_CNT + 1);
val |= 0x08;
outb (val, TCO1_CNT + 1);
val = inb (TCO1_CNT + 1);
+
+ /* Set the NO_REBOOT bit to prevent later reboots, just for sure */
+ pci_read_config_byte (i8xx_tco_pci, 0xd4, );
+ val1 |= 0x02;
+ pci_write_config_byte (i8xx_tco_pci, 0xd4, val1);
+
spin_unlock(_lock);
if ((val & 0x08) == 0)
@@ -155,6 +173,7 @@
static int tco_timer_keepalive (void)
{
spin_lock(_lock);
+ /* Reload the timer by writing to the TCO Timer Reload register */
outb (0x01, TCO1_RLD);
spin_unlock(_lock);
return 0;
@@ -417,9 +436,8 @@
printk (KERN_ERR PFX "failed to get TCOBASE address\n");
return 0;
}
- /*
-* Check chipset's NO_REBOOT bit
-*/
+
+ /* Check chipset's NO_REBOOT bit */
pci_read_config_byte (i8xx_tco_pci, 0xd4, );
if (val1 & 0x02) {
val1 &= 0xfd;
@@ -430,6 +448,10 @@
return 0; /* Cannot reset NO_REBOOT bit */
}
}
+ /* Disable reboots untill the watchdog starts */
+ val1 |= 0x02;
+ pci_write_config_byte (i8xx_tco_pci, 0xd4, val1);
+
/* Set the TCO_EN bit in SMI_EN register */
if (!request_region (SMI_EN + 1, 1, "i8xx TCO")) {
printk (KERN_ERR PFX "I/O address 0x%04x already in
use\n",
@@ -505,17 +527,10 @@
static void __exit watchdog_cleanup (void)
{
- u8 val;
-
/* Stop the timer before we leave */
if (!nowayout)
tco_timer_stop ();
- /* Set the NO_REBOOT bit to prevent later reboots, just for sure */
- pci_read_config_byte (i8xx_tco_pci, 0xd4, );
- val |= 0x02;
- pci_write_config_byte (i8xx_tco_pci, 0xd4, val);
-
/* Deregister */
misc_deregister (_tco_miscdev);
unregister_reboot_notifier(_tco_notifier);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] remove warning about e1000_suspend
e1000_suspend is only used under #ifdef CONFIG_PM. Move the declaration
of it to be the same way, just like e1000_resume, otherwise gcc whines
on compile. I offer as evidence:
static struct pci_driver e1000_driver = {
.name = e1000_driver_name,
.id_table = e1000_pci_tbl,
.probe= e1000_probe,
.remove = __devexit_p(e1000_remove),
/* Power Managment Hooks */
#ifdef CONFIG_PM
.suspend = e1000_suspend,
.resume = e1000_resume
#endif
};
diff -aurpN -X /home/fletch/.diff.exclude virgin/drivers/net/e1000/e1000_main.c
e1000_suspend/drivers/net/e1000/e1000_main.c
--- virgin/drivers/net/e1000/e1000_main.c 2005-08-07 09:15:36.0
-0700
+++ e1000_suspend/drivers/net/e1000/e1000_main.c2005-08-07
12:10:42.0 -0700
@@ -162,8 +162,8 @@ static void e1000_vlan_rx_add_vid(struct
static void e1000_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid);
static void e1000_restore_vlan(struct e1000_adapter *adapter);
-static int e1000_suspend(struct pci_dev *pdev, uint32_t state);
#ifdef CONFIG_PM
+static int e1000_suspend(struct pci_dev *pdev, uint32_t state);
static int e1000_resume(struct pci_dev *pdev);
#endif
@@ -3641,6 +3641,7 @@ e1000_set_spd_dplx(struct e1000_adapter
return 0;
}
+#ifdef CONFIG_PM
static int
e1000_suspend(struct pci_dev *pdev, uint32_t state)
{
@@ -3733,7 +3734,6 @@ e1000_suspend(struct pci_dev *pdev, uint
return 0;
}
-#ifdef CONFIG_PM
static int
e1000_resume(struct pci_dev *pdev)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL generates "is deprecated" noise
On Sun, Aug 07, 2005 at 11:07:59AM -0700, Martin J. Bligh wrote: > I'm getting lots of errors like this nowadays: > > drivers/serial/8250.c:2651: warning: `register_serial' is deprecated > (declared at drivers/serial/8250.c:2607) > > Which is just: "EXPORT_SYMBOL(register_serial);" > > Sorry, but that's just compile-time noise, not anything useful. > Warning on real usages of it might be handy (we can go fix the users) > but not EXPORT_SYMBOL - we can't kill the export until the function > goes away. The more noise we have, the harder it is to see real errors > and warnings. I don't know why I bother with __deprecated - I haven't seen much evidence of the users of these functions being cleaned up, so I think we might as well just delete the functions and _force_ people to fix their code. That unfortunately seems to be the only way to get things done in this day and age, which is rather sad if that's what it takes to kick people into action. -- 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: EXPORT_SYMBOL generates "is deprecated" noise
>> If it's going to spout crap when I'm not even using the deprecated >> function, it's worse than useless, I'm afraid. >> ... > > It's reminding us that we are still offering a deprecated function. ;-) Might be useful as an option. But not to irritate every poor sod who does a kernel compile, ever. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL generates "is deprecated" noise
On Sun, Aug 07, 2005 at 11:55:16AM -0700, Martin J. Bligh wrote: > > > --Adrian Bunk <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 20:23:12 > +0200): > > > On Sun, Aug 07, 2005 at 11:07:59AM -0700, Martin J. Bligh wrote: > >> I'm getting lots of errors like this nowadays: > >> > >> drivers/serial/8250.c:2651: warning: `register_serial' is deprecated > >> (declared at drivers/serial/8250.c:2607) > >> > >> Which is just: "EXPORT_SYMBOL(register_serial);" > >> > >> Sorry, but that's just compile-time noise, not anything useful. > >> Warning on real usages of it might be handy (we can go fix the users) > >> but not EXPORT_SYMBOL - we can't kill the export until the function > >> goes away. The more noise we have, the harder it is to see real errors > >> and warnings. > >> > >> I took a quick poke around, but can't see what generates this stuff. > >> What is doing these checks, and can we please make an exception for > >> EXPORT_SYMBOL (and EXPORT_SYMBOL_GPL) somehow? > > > > This is generated by the __deprecated marker (#define'd to > > __attribute__((deprecated)) ) at the prototype in > > include/linux/serial.h. > > > > You could somehow #ifdef the warning away, but IMHO this would be more > > ugly than living with the warning until the last user is gone. > > If it's going to spout crap when I'm not even using the deprecated > function, it's worse than useless, I'm afraid. >... It's reminding us that we are still offering a deprecated function. ;-) > M. 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/
[PATCH] get rid of warning in aic7770.c:aic7770_config()
Get rid of unused variable warning:
drivers/scsi/aic7xxx/aic7770.c: In function `aic7770_config':
drivers/scsi/aic7xxx/aic7770.c:129: warning: unused variable `l'
Not used anywhere in the function, even under ifdef. Delete.
diff -aurpN -X /home/fletch/.diff.exclude virgin/drivers/scsi/aic7xxx/aic7770.c
aic_warning/drivers/scsi/aic7xxx/aic7770.c
--- virgin/drivers/scsi/aic7xxx/aic7770.c 2005-08-07 09:15:41.0
-0700
+++ aic_warning/drivers/scsi/aic7xxx/aic7770.c 2005-08-07 11:58:41.0
-0700
@@ -126,7 +126,6 @@ aic7770_find_device(uint32_t id)
int
aic7770_config(struct ahc_softc *ahc, struct aic7770_identity *entry, u_int io)
{
- u_long l;
int error;
int have_seeprom;
u_int hostconf;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/1] i386 Encapsulate copying of pgd entries
Hi! > This helps complete the encapsulation of updates to page tables (or pages > about to become page tables) into accessor functions rather than using > memcpy() to duplicate them. This is both generally good for consistency > and also necessary for running in a hypervisor which requires explicit > updates to page table entries. Hmm, I'm not sure if this kind of hypervisor can reasonably work with swsusp; swsusp is just copying memory, it does not know which part of memory are page tables. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FYI: device_suspend(...) in kernel_power_off().
Hi! > There as been a fair amount of consensus that calling > device_suspend(...) in the reboot path was inappropriate now, because > the device suspend code was too immature. With this latest > piece of evidence it seems to me that introducing device_suspend(...) > in kernel_power_off, kernel_halt, kernel_reboot, or kernel_kexec > can never be appropriate. Code is not ready now => it can never be fixed? Thats quite a strange conclusion to make. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech Quickcam Express USB Address Aquisition Issues
On Sunday 07 Aug 2005 19:54, Alistair John Strachan wrote: > On Sunday 07 Aug 2005 12:36, christos gentsis wrote: > [snip] > > > > I searched up google a bit and recieved some warnings about acpi > > > causing problems, so I disabled that, but was still unsucessful in > > > getting that to work. Please let me know if any other information is > > > required. Thanks ahead of time. > > > > > > Chris White > > > > does the drivers for the Phillips web cams come back to the kernel? > > because i thought that it was taken out... > > > > http://www.smcc.demon.nl/webcam/ > > > > check this site and see if your cam was one of the cams that supported > > from the driver that discontinue... so if is supported by this driver, > > download and install it... it works i try it with my cam ;) > > The in-kernel pwc driver doesn't work for me either. I highly recommend you > try the above if this turns out to not be a hardware fault. Sorry, I didn't even check the link. Try the driver from: http://www.saillard.org/linux/pwc/ Which seems to work better. -- 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: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace
Hi! > > > > Could you tell me why you don't just fail the operation if malformed > > > > input is supplied? > > > > > > Leading/trailing white space should be allowed. For example echo > > > appends '\n' unless you know to use -n. It is easier to fix the kernel > > > than to teach everyone to use -n. > > > > Please, NO! echo -n is the right thing to do, and users will eventually > > learn. > > We are not going to add such workarounds all over the kernel... > > It is not a work around. These are text attributes meant for human > use. Humans have a hard time cleaning up things they can't see. And > the failure mode for this is awful, your attribute won't set but > everything on the screen looks fine. Kernel is not a place to be user friendly. Or do you propose stripping whitespace for open(), too? File called "foo.txt" certainly *is* going to be confusing, but it should be allowed at kernel level. Now... echo foo > /sys/var does not properly report errors. Thats bad, but it needs to be fixed in bash. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL generates "is deprecated" noise
--Adrian Bunk <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 20:23:12 +0200): > On Sun, Aug 07, 2005 at 11:07:59AM -0700, Martin J. Bligh wrote: >> I'm getting lots of errors like this nowadays: >> >> drivers/serial/8250.c:2651: warning: `register_serial' is deprecated >> (declared at drivers/serial/8250.c:2607) >> >> Which is just: "EXPORT_SYMBOL(register_serial);" >> >> Sorry, but that's just compile-time noise, not anything useful. >> Warning on real usages of it might be handy (we can go fix the users) >> but not EXPORT_SYMBOL - we can't kill the export until the function >> goes away. The more noise we have, the harder it is to see real errors >> and warnings. >> >> I took a quick poke around, but can't see what generates this stuff. >> What is doing these checks, and can we please make an exception for >> EXPORT_SYMBOL (and EXPORT_SYMBOL_GPL) somehow? > > This is generated by the __deprecated marker (#define'd to > __attribute__((deprecated)) ) at the prototype in > include/linux/serial.h. > > You could somehow #ifdef the warning away, but IMHO this would be more > ugly than living with the warning until the last user is gone. If it's going to spout crap when I'm not even using the deprecated function, it's worse than useless, I'm afraid. I tried some "smart" nested definitions to just wrap it inside EXPORT_SYMBOL, but the ordering of evaluation is all wrong. Bah ;-( M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace
Hi! > > > If we are going back to needing helper scripts then I should just > > > remove the entire sysfs graphics interface and switch back to using > > > ioctls and a helper app. Of could no one can ever find the helper app > > > or remember how it works. I thought one of the main reasons behind the > > > sysfs interface was to eliminate these helper apps. > > > > The point is that you _can_ do it with echo, not that it is _easy_. > > Nor is sysfs a solution in any case. > > > > > Without doing whitespace cleanup there is a 100% probability that this > > > will generate bug reports. I know this for a fact because I am already > > > getting them. > > > > Stupid users are not a reason for kernel bloat. > > You have a very wrapped sense of kernel bloat. This is nine lines of > code whose absence is guaranteed to generate a bunch of bug reports. > Not having it is also causing various implementers to implement > attribute processing differently. Some are stripping white space in > their implementations and some are not. If you want to attack kernel Can you point place where we do strip whitespace in kernel sysfs handlers? Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
