Re: XFS or Kernel Problem / Bug
Hi! I'm not shure but perhaps it isn't an XFS Bug. Here is what i find out: We've about 300 servers at the momentan and 5 of them are "old" Intel Pentium 4 Machines with a DFI PM-12 Mainboard with VIA chipset. It only happens on THESE Machines. Other P4 Machines with a Tyan Mainboard or a Gigabyte Mainboard are not affected. All 300 machines runs the same Debian 3.0 with self build kernel. Some of these 5 use a 3ware controller and some of them the mainboardcontroller. All systems are using IDE. But i cannot say what happens to these machines at the time of failure. Sometimes these servers crashed directly after a few minutes. Sometimes they run about 2-3 days... i've now downgraded all servers to 2.6.16.37. Cause they are production machines... but i have one machine where we can test - if you need something. Here is the output running 2.6.16.37 at the moment: xfs_growfs -n / meta-data=/dev/root isize=256agcount=16, agsize=603855 blks = sectsz=512 attr=0 data = bsize=4096 blocks=9661680, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=4717, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Stefan David Chinner schrieb: On Sun, Jan 21, 2007 at 01:30:15PM +0100, Stefan Priebe - FH wrote: Hello! I've 3 Servers which works wonderful with 2.6.16.X (also testet the latest 2.6.16.37) but with 2.6.18.6 i get these errors: [ EIP is at xfs_bmap_add_extent_hole_delay+0x58d/0x59b ] [ EIP is at generic_file_buffered_write+0x390/0x6cf ] Do you have a reproducable test case for these? if not, do you have any idea what is going on in the system at the time of the failure? Can you describe the storage subsystem you are using and post the output of xfs_growfs -n on the filesystem that is causing problems? Cheers, 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/
[Need Help] Cpuhotplug operations on 32-bit mode of xeon-64bit processor crashes the system.
I saw cpuhotplug operations on 32-bit mode of xeon-64bit processors crashing the system. This happens on latest 2.6.20-rc5 kernel also. Same (i386 cpuhotplug code) runs fine on xeon-32bit processors. Steps to reproduce. echo 0 > /sys/devices/system/cpu/cpu6/online echo 1 > /sys/devices/system/cpu/cpu6/online dmesg shows. == Breaking affinity for irq 4 cpu_mask_to_apicid: Not a valid mask! CPU 6 is now offline === On debugging the problem, I found that problem is not in cpuhotplug code but in apic part. Execution of "stale" IPI's by onlined cpus(which we offlined earlier) is causing the crash. Now we need to debug,why IPI's are reaching the offlined cpu's too. 1) During the calculation of apicid's, if cpu to which IPI has to deliver is not in same apic cluster,it prints "Not a valid mask" error and returns "0xFF" which means broadcast the IPI's to all cpus(which are offlined too) and hence the problem. 2) I booted the system with maxcpus=2 boot parameter, and tried cpu hotplugging on it. but still problem recreates(I think there is no concept of apic clusters if there are only 2 cpus). Hence it makes me to conclude that problem is in delivery of IPI's. So Iam completely stuck here. Iam not able to move forward in debugging. So could someone(may be intel folks) please throw some light on this. Thanks in advance Srinivasa DS LTC-IBM - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problems with latest smbfs changes on 2.4.34 and security backports
On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote: >On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote: >Ah, think I see the problem now: > >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 17:53:57.247695476 >-0700 >+++ kernel-source-2.4.27/fs/smbfs/proc.c 2007-01-19 17:49:07.480161733 >-0700 >@@ -1997,7 +1997,7 @@ > fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | > S_IRWXO)) | S_IFDIR; > else if ( (server->mnt->flags & SMB_MOUNT_FMODE) && > !(S_ISDIR(fattr->f_mode)) ) >- fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | >S_IRWXO)) | S_IFREG; >+ fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | >S_IRWXO)) | (fattr->f_mode & S_IFMT); > > } > client running 2.4.34 with above patch, server is running 2.6.19.2 to eliminate it from the problem space (hopefully ;) : [EMAIL PROTECTED]:/home/other$ uname -r 2.4.34b [EMAIL PROTECTED]:/home/other$ ls -l total 9 drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/ drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/ -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file* -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 filelink* [EMAIL PROTECTED]:/home/other$ ls -l dirlink/ total 1 -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 file* -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 filelink* [EMAIL PROTECTED]:/home/other$ problem is still there :( With client 2.4.33.3 (slackware-11 distro kernel): [EMAIL PROTECTED]:/home/other$ uname -r 2.4.33.3 [EMAIL PROTECTED]:/home/other$ ls -l total 2048 drwxr-xr-x 1 root root 0 2007-01-21 11:44 dir/ lrwxrwxrwx 1 root root 3 2007-01-21 11:43 dirlink -> dir/ -rw-r--r-- 1 root root 15 2007-01-21 11:43 file lrwxrwxrwx 1 root root 4 2007-01-21 11:44 filelink -> file [EMAIL PROTECTED]:/home/other$ ls -l dirlink/ total 2048 -rw-r--r-- 1 root root 15 2007-01-21 11:44 file lrwxrwxrwx 1 root root 4 2007-01-21 11:44 filelink -> file [EMAIL PROTECTED]:/home/other$ cat filelink this is a test No problem with symlinks, execute flag. Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.20-rc5 1/1] MM: enhance Linux swap subsystem
My patch is based on my new idea to Linux swap subsystem, you can find more in
Documentation/vm_pps.txt which isn't only patch illustration but also file
changelog. In brief, SwapDaemon should scan and reclaim pages on
UserSpace::vmalist other than current zone::active/inactive. The change will
conspicuously enhance swap subsystem performance by
1) SwapDaemon can collect the statistic of process acessing pages and by it
unmaps ptes, SMP specially benefits from it for we can use flush_tlb_range
to unmap ptes batchly rather than frequently TLB IPI interrupt per a page in
current Linux legacy swap subsystem.
2) Page-fault can issue better readahead requests since history data shows all
related pages have conglomerating affinity. In contrast, Linux page-fault
readaheads the pages relative to the SwapSpace position of current
page-fault page.
3) It's conformable to POSIX madvise API family.
4) It simplifies Linux memory model dramatically. Keep it in mind that new swap
strategy is from up to down. In fact, Linux legacy swap subsystem is maybe
the only one from down to up.
Other problems asked about my pps are
1) There isn't new lock order in my pps, it's compliant to Linux lock order
defined in mm/rmap.c.
2) When a memory inode is low, you can set scan_control::reclaim_node to let my
kppsd to reclaim the memory inode page.
Signed-off-by: Yunfeng Zhang <[EMAIL PROTECTED]>
Index: linux-2.6.19/Documentation/vm_pps.txt
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.19/Documentation/vm_pps.txt 2007-01-22 13:52:04.973820224
+0800
@@ -0,0 +1,237 @@
+ Pure Private Page System (pps)
+ Copyright by Yunfeng Zhang on GFDL 1.2
+ [EMAIL PROTECTED]
+ December 24-26, 2006
+
+// Purpose <([{
+The file is used to document the idea which is published firstly at
+http://www.ussg.iu.edu/hypermail/linux/kernel/0607.2/0451.html, as a part of my
+OS -- main page http://blog.chinaunix.net/u/21764/index.php. In brief, the
+patch of the document is for enchancing the performance of Linux swap
+subsystem. You can find the overview of the idea in section and how I patch it into Linux 2.6.19 in section
+.
+// }])>
+
+// How to Reclaim Pages more Efficiently <([{
+Good idea originates from overall design and management ability, when you look
+down from a manager view, you will relief yourself from disordered code and
+find some problem immediately.
+
+OK! to modern OS, its memory subsystem can be divided into three layers
+1) Space layer (InodeSpace, UserSpace and CoreSpace).
+2) VMA layer (PrivateVMA and SharedVMA, memory architecture-independent layer).
+3) Page table, zone and memory inode layer (architecture-dependent).
+Maybe it makes you sense that Page/PTE should be placed on the 3rd layer, but
+here, it's placed on the 2nd layer since it's the basic unit of VMA.
+
+Since the 2nd layer assembles the much statistic of page-acess information, so
+it's nature that swap subsystem should be deployed and implemented on the 2nd
+layer.
+
+Undoubtedly, there are some virtues about it
+1) SwapDaemon can collect the statistic of process acessing pages and by it
+ unmaps ptes, SMP specially benefits from it for we can use flush_tlb_range
+ to unmap ptes batchly rather than frequently TLB IPI interrupt per a page in
+ current Linux legacy swap subsystem.
+2) Page-fault can issue better readahead requests since history data shows all
+ related pages have conglomerating affinity. In contrast, Linux page-fault
+ readaheads the pages relative to the SwapSpace position of current
+ page-fault page.
+3) It's conformable to POSIX madvise API family.
+4) It simplifies Linux memory model dramatically. Keep it in mind that new swap
+ strategy is from up to down. In fact, Linux legacy swap subsystem is maybe
+ the only one from down to up.
+
+Unfortunately, Linux 2.6.19 swap subsystem is based on the 3rd layer -- a
+system on memory node::active_list/inactive_list.
+
+I've finished a patch, see section . Note, it
+ISN'T perfect.
+// }])>
+
+// Pure Private Page System -- pps <([{
+As I've referred in previous section, perfectly applying my idea need to unroot
+page-surrounging swap subsystem to migrate it on VMA, but a huge gap has
+defeated me -- active_list and inactive_list. In fact, you can find
+lru_add_active code anywhere ... It's IMPOSSIBLE to me to complete it only by
+myself. It's also the difference between my design and Linux, in my OS, page is
+the charge of its new owner totally, however, to Linux, page management system
+is still tracing it by PG_active flag.
+
+So I conceive another solution:) That is, set up an independent page-recycle
+system rooted on Linux legacy page system -- pps, intercept all private pages
+belonging to PrivateVMA to pps, then use my pps to cycle them. By the way, the
+whole
2007 Linux Kernel Summit
Hi folks, It's time to start kicking off the 2007 Kernel Summit planning process. This year, the Kernel Summit will be held in Cambridge, England, at the DeVere University Arms Hotel, September 5-6 (with a welcome reception on the 4th). The decision to move the Kernel Summit to England is a one-year experiment based on the very strong request of last year's kernel summit attendees to try a location outside of Ottawa, and especially from the roughly 1/3rd of the attendees that come from the UK or Europe. So the plan is for us to book the Ottawa Congress Ceter space for July 2008 (which we will need to do by mid-year 2007), and pending how well the Cambridge venue works out in September 2007, we'll figure out how often we want to try moving the Kernel Summit to other locations in future years beyond 2008. (It'd be great to fantasize pairing the Kernel Summit with Linux.conf.au, but unless we can get some sponsor's CEO offers up their personal jet, or we pick up a major airline as a sponsor, it's not likely to happen any time soon due to the reality of corporate travel budgets. :-) As in previous years, I've set up a e-mail discussion list for people who are interested in making suggestions for this year's kernel summit. In the probably hopeless attempt to avoid the list address getting instantly harvested by spammers from all of the LKML archives, the list submission address and subscription URL can be found by executing the following perl script: #!/usr/bin/perl $at="@"; $AD=(gmtime(time))[5]+1900; print "ksummit-" . $AD . "-discuss" . $at . "thunk.org\n"; print "http://thunk.org/mailman/listinfo/ksummit-; . $AD . "-discuss\n"; More announcements about the topic and attendee selection process will be made in the next week or so on the discuss list, but in the meantime, if there are any folks who are interested in putting together mini-summits or workshops for various kernel subsystems at Ottawa on the 25th or 26th, please let me know. It may be possible for Usenix to make some hotel conference rooms available, to provide an opportunity for kernel development teams who want to get together before OLS and the Kernel Summit to do so. Finally, let me introduce to this year's program committee: Jens Axboe James Bottomley Jonathon Corbet Dirk Hohndel Gerrit Huizenga Dave Jones Andi Kleen Greg Kroah-Hartman Steve Hemminger Matthew Mackall Andrew Morton Theodore Ts'o If you have any questions, please feel to contact me or the entire kernel summit program committee. Our contact e-mail address can be found by taking the output from the above perl script and running it through the command: "sed -e 's/discuss/pc/'". Regards, - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
> "Tony" == Tony Foiani <[EMAIL PROTECTED]> writes: Tony> How fast is your Ethernet port? 100Mbps or 95.37Mbps? > "Jan" == Jan Engelhardt <[EMAIL PROTECTED]> writes: Jan> Same lie like with harddrives. It's around 80, not 100. But it Jan> depends on how you look at it. 80 for Layer3, possibly a little Jan> more for Layer2/1. No, it's not the same lie. The physical media -- as presented to the next higher layer -- really has 100Mbps capability. Likewise, the "physical media" of a hard drive (as seen outside the controller on the disk) really is 500GB/465GiB (or whatever). [1] The overhead caused by Ethernet frames (level 2) and then IP packets (level 3) and then TCP or UDP (level 4) are more closely related to the losses you get on filesystem overhead (superblock, inodes, directories) and "slack" in block-allocated systems (having to round sizes up to the next 512 or whatever). [2] The problem is that a drive labelled "500GB" on its packaging is displayed as "465GB" on the computer. The fix is to have the computer display either "500GB" or "465GiB". t. [1] SFAIK, what's really on hard drive platters anymore is something much closer to "symbols", not just 1s and 0s. In the same way that "baud" is "symbols per second", the actual thingies on the platters are symbols, and it's up to the drive electronics to make sense of them. [2] Level numbers from: http://en.wikipedia.org/wiki/TCP/IP_model - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.19.2, cp 18gb_file 18gb_file.2 = OOM killer, 100% reproducible (multi-threaded USB no go)
On Sun, Jan 21, 2007 at 12:29:51PM -0500, Justin Piszcz wrote: > > > On Sun, 21 Jan 2007, Justin Piszcz wrote: > > > > > > > > > > > Good luck, > > > Jurriaan > > > -- > > > > What does ELF stand for (in respect to Linux?) > > > ELF is the first rock group that Ronnie James Dio performed with back in > > > the early 1970's. In constrast, a.out is a misspellingof the French > > > word > > > for the month of August. What the two have in common is beyond me, but > > > Linux users seem to use the two words together. > > > seen on c.o.l.misc > > > Debian (Unstable) GNU/Linux 2.6.20-rc5 2x2011 bogomips load 0.83 > > > the Jack Vance Integral Edition: http://www.integralarchive.org > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > Thanks, I'll give it another go in a bit! > > > > Justin. > > - > > Running 2.6.20-rc5 now, the multi-threaded USB probing causes my UPS not > to work, probably because udev has problems or something, it is also the > only USB device I have plugged into the machine. multi-threaded USB is about to go away as it caused too many problems for people, and they didn't read the Kconfig help entry about it :( thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS or Kernel Problem / Bug
On Sun, Jan 21, 2007 at 01:30:15PM +0100, Stefan Priebe - FH wrote: > Hello! > > I've 3 Servers which works wonderful with 2.6.16.X (also testet the > latest 2.6.16.37) > > but with 2.6.18.6 i get these errors: [ EIP is at xfs_bmap_add_extent_hole_delay+0x58d/0x59b ] [ EIP is at generic_file_buffered_write+0x390/0x6cf ] Do you have a reproducable test case for these? if not, do you have any idea what is going on in the system at the time of the failure? Can you describe the storage subsystem you are using and post the output of xfs_growfs -n on the filesystem that is causing problems? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] bidi support: request dma_data_direction
Douglas Gilbert wrote: > Boaz Harrosh wrote: >> - Introduce a new enum dma_data_direction data_dir member in struct request. >> and remove the RW bit from request->cmd_flag >> - Add new API to query request direction. >> - Adjust existing API and implementation. >> - Cleanup wrong use of DMA_BIDIRECTIONAL >> - Introduce new blk_rq_init_unqueued_req() and use it in places ad-hoc >> requests were used and bzero'ed. > > With a bi-directional transfer is it always unambiguous > which transfer occurs first (or could they occur at > the same time)? The bidi transfers can occur in any order and in parallel. > > Doug Gilbert > - > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.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: [RFC 1/6] bidi support: request dma_data_direction
On Mon, Jan 22, 2007 at 01:21:28AM +0200, Boaz Harrosh wrote:
> - Introduce a new enum dma_data_direction data_dir member in struct request.
> and remove the RW bit from request->cmd_flag
Some architecture use 'enum dma_data_direction' and some 'int
dma_data_direction'. The consensus was to move to int over
time. Please use 'int dma_data_direction'.
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index ff203c4..abbca7b 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -13,6 +13,28 @@ enum dma_data_direction {
> DMA_NONE = 3,
> };
>
> +static inline int dma_write_dir(enum dma_data_direction dir)
> +{
> + return (dir == DMA_TO_DEVICE) || (dir == DMA_BIDIRECTIONAL);
> +}
"write" can mean "write to device" or "write to memory", depending on
context. Not exactly something which should be a generic
helper. Rename to 'dma_to_device(int dir)'?
> +static inline int dma_uni_dir(enum dma_data_direction dir)
> +{
> + return (dir == DMA_TO_DEVICE) || (dir == DMA_FROM_DEVICE) ||
> +(dir == DMA_NONE);
> +}
While this doesn't look very useful. Why is "DMA_NONE" a uni-dir? I
suggest replacing this with an open coded (dir != DMA_BIDIRECTIONAL).
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH] Register the bus, vendor and product IDs for dvb-usb remote device
Chris Rankin wrote:
> Hi,
>
> This patch writes the USB vendor and product IDs into the
> /sys/class/input/inputX/id/ files, so
> that udev can find them. A rule like this does the trick for me:
>
> KERNEL="event*", SYSFS{../id/vendor}=="2040", SYSFS{../id/product}=="9301",
> SYMLINK+="input/dvb-remote"
>
> --- linux-2.6.18/drivers/media/dvb/dvb-usb/dvb-usb-remote.c.old 2007-01-21
> 02:43:11.0
> +
> +++ linux-2.6.18/drivers/media/dvb/dvb-usb/dvb-usb-remote.c 2007-01-21
> 02:39:02.0
> +
> @@ -107,6 +107,9 @@
> d->rc_input_dev->keycodemax = KEY_MAX;
> d->rc_input_dev->name = "IR-receiver inside an USB DVB receiver";
> d->rc_input_dev->phys = d->rc_phys;
> + d->rc_input_dev->id.bustype = BUS_USB;
> + d->rc_input_dev->id.vendor = d->udev->descriptor.idVendor;
> + d->rc_input_dev->id.product = d->udev->descriptor.idProduct;
>
> /* set the bits for the keys */
> deb_rc("key map size: %d\n", d->props.rc_key_map_size);
Chris,
The patch is fine. Could you please provide a sign-off, in the form:
Signed-off-by: Your Name <[EMAIL PROTECTED]>
...so that we can apply this to the kernel sources?
Cheers,
Mike Krufky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Suspend to RAM generates oops and general protection fault
Hi. On Mon, 2007-01-22 at 16:16 +1100, Jean-Marc Valin wrote: > >> I just encountered the following oops and general protection fault > >> trying to suspend/resume my laptop. I've got a Dell D820 laptop with a 2 > >> GHz Core 2 Duo CPU. It usually suspends/resumes fine but not always. The > >> relevant errors are below but the full dmesg log is at > >> http://people.xiph.org/~jm/suspend_resume_oops.txt and my config is in > >> http://people.xiph.org/~jm/config-2.6.20-rc5.txt > ... > > It looks like something is stomping on memory it shouldn't be touching, > > so I would suggest testing multiple cycles with a minimal (preferably > > zero) number of modules loaded. If that looks good and reliable, add > > modules & processes until you can say 'If I do X, it breaks.'. If having > > a minimal number of modules loaded doesn't help, I would then suggest > > reviewing your kernel config to see if other things can be built as > > modules and the same logic applied. You can be reasonably sure that it > > will be a device driver. Common causes of suspend/resume problems from > > the list you give below are acpi modules, bluetooth and usb. I'd also be > > consider pcmcia, drm and fuse possibilities. But again, go for unloading > > everything possible in the first instance. > > Actually, the reason I sent this is that when I showed the oops/gpf to > Matthew Garrett at linux.conf.au, he said it looked like a CPU hotplug > problem and suggested I send it to lkml. BTW, with 2.6.20-rc5, the > suspend to RAM now works ~95% of the time. I agree that the second is cpu hotplug, but the first is something else, hence my recommendations above. Regards, Nigel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Suspend to RAM generates oops and general protection fault
>> I just encountered the following oops and general protection fault >> trying to suspend/resume my laptop. I've got a Dell D820 laptop with a 2 >> GHz Core 2 Duo CPU. It usually suspends/resumes fine but not always. The >> relevant errors are below but the full dmesg log is at >> http://people.xiph.org/~jm/suspend_resume_oops.txt and my config is in >> http://people.xiph.org/~jm/config-2.6.20-rc5.txt ... > It looks like something is stomping on memory it shouldn't be touching, > so I would suggest testing multiple cycles with a minimal (preferably > zero) number of modules loaded. If that looks good and reliable, add > modules & processes until you can say 'If I do X, it breaks.'. If having > a minimal number of modules loaded doesn't help, I would then suggest > reviewing your kernel config to see if other things can be built as > modules and the same logic applied. You can be reasonably sure that it > will be a device driver. Common causes of suspend/resume problems from > the list you give below are acpi modules, bluetooth and usb. I'd also be > consider pcmcia, drm and fuse possibilities. But again, go for unloading > everything possible in the first instance. Actually, the reason I sent this is that when I showed the oops/gpf to Matthew Garrett at linux.conf.au, he said it looked like a CPU hotplug problem and suggested I send it to lkml. BTW, with 2.6.20-rc5, the suspend to RAM now works ~95% of the time. Jean-Marc > Regards, > > Nigel > >> Cheers, >> >> Jean-Marc >> >> P.S. This is the same laptop I had at LCA for which Linus told me to >> disable preemption and try the newest rc version. >> >> [10746.449071] Unable to handle kernel NULL pointer dereference at >> 0038 RIP: >> [10746.449080] [] iput+0x18/0x80 >> [10746.449092] PGD 3a607067 PUD 27b20067 PMD 0 >> [10746.449099] Oops: [1] SMP >> [10746.449104] CPU 0 >> [10746.449107] Modules linked in: psmouse battery ac thermal fan button >> ipw3945 ieee80211 tg3 arc4 ecb blkcipher ieee80211_crypt_wep >> ieee80211_crypt binfmt_misc rfcomm l2cap bluetooth i915 drm >> speedstep_centrino cpufreq_userspace cpufreq_powersave cpufreq_ondemand >> cpufreq_stats freq_table cpufreq_conservative video sbs i2c_ec dock >> asus_acpi backlight container ipv6 fuse sbp2 af_packet parport_pc lp >> parport sg sr_mod cdrom snd_hda_intel snd_hda_codec tsdev snd_pcm_oss >> snd_mixer_oss pcmcia snd_pcm snd_timer ata_generic snd shpchp >> pci_hotplug soundcore snd_page_alloc serio_raw yenta_socket >> rsrc_nonstatic pcmcia_core pcspkr evdev ext3 jbd mbcache ohci1394 >> ehci_hcd ieee1394 ide_generic uhci_hcd usbcore generic sd_mod processor >> [10746.449190] Pid: 218, comm: kswapd0 Not tainted 2.6.20-rc5-x86-64 #1 >> [10746.449196] RIP: 0010:[] [] >> iput+0x18/0x80 >> [10746.449206] RSP: :810037f2dd50 EFLAGS: 00010283 >> [10746.449212] RAX: RBX: 8103fcf0 RCX: >> 8103fd20 >> [10746.449219] RDX: 0001 RSI: 0286 RDI: >> 8103fcf0 >> [10746.449225] RBP: 0042 R08: R09: >> >> [10746.449232] R10: 28f5c28f5c28f5c3 R11: 8023ae90 R12: >> >> [10746.449239] R13: 810075721c70 R14: 805fa940 R15: >> >> [10746.449246] FS: () GS:8058e000() >> knlGS: >> [10746.449253] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b >> [10746.449259] CR2: 0038 CR3: 1207f000 CR4: >> 06e0 >> [10746.449265] Process kswapd0 (pid: 218, threadinfo 810037f2c000, >> task 810037a1b760) >> [10746.449269] Stack: 811ce2f0 802ddaf8 >> 811ce3c0 811ce2f0 >> [10746.449280] 0042 8022f645 810037f2dd80 >> 0001cb60 >> [10746.449288] 0090 81007daa0e00 00d0 >> 802ddb49 >> [10746.449296] Call Trace: >> [10746.449305] [] prune_one_dentry+0x68/0xa0 >> [10746.449314] [] prune_dcache+0x145/0x1e0 >> [10746.449323] [] shrink_dcache_memory+0x19/0x50 >> [10746.449331] [] shrink_slab+0x117/0x190 >> [10746.449342] [] kswapd+0x382/0x4e0 >> [10746.449356] [] autoremove_wake_function+0x0/0x30 >> [10746.449370] [] kswapd+0x0/0x4e0 >> [10746.449376] [] keventd_create_kthread+0x0/0x90 >> [10746.449383] [] kthread+0xd9/0x120 >> [10746.449394] [] child_rip+0xa/0x12 >> [10746.449401] [] keventd_create_kthread+0x0/0x90 >> [10746.449414] [] kthread+0x0/0x120 >> [10746.449421] [] child_rip+0x0/0x12 >> [10746.449426] >> [10746.449429] >> [10746.449430] Code: 48 8b 40 38 75 04 0f 0b eb fe 48 85 c0 74 0b 48 8b >> 40 28 48 >> [10746.449449] RIP [] iput+0x18/0x80 >> [10746.449456] RSP >> [10746.449460] CR2: 0038 >> [10746.449463] ACPI Exception (pci_bind-0299): AE_NOT_FOUND, Unable to >> get data from device DCKS [20060707] >> >> >> and later: >> >> >> [3.668009] SMP alternatives: switching to SMP code >> [3.668168] Booting
Re: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
On 2007.01.18 23:16:51 +, Pavel Machek wrote: > Hi! > > > > > Especially the PCI video_state trick finally got me a working resume on > > > > 2.6.19-ck2 r128 Rage Mobility M4 AGP *WITH*(!) fully enabled and working > > > > (and keeping working!) DRI (3D). > > > > > > Can we get whitelist entry for suspend.sf.net? s2ram from there can do > > > all the tricks you described, one letter per trick :-). We even got > > > PCI saving lately. > > > > Whitelist? Let me blacklist it all the way to Timbuktu instead! > > > I've been doing more testing, and X never managed to come back to working > > state without some of my couple intel-agp changes: > > - a proper suspend method, doing a proper pci_save_state() > > or improved equivalent > > - a missing resume check for my i815 chipset > > - global cache flush in _configure > > - restoring AGP bridge PCI config space > > Can you post a patch? I've post a patch which trys to resolve pci config restore issue, see http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine, that my X can come back to live after s3, but I wasn't aware of the issues Andreas has noted. It'll be good if more people could try this out. > Whitelist entry would still be welcome. > > > All in all intel-agp code semi-shattered my universe. > > I didn't expect to find all these issues in rather important core code > ... > > Given the myriads of resume issues we experience in general, > > it may be wise to do something as simple as a code review of *all* > > Any volunteers? > Pavel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] some rtc documentation updates
find attached a patch to update the rtc documentation a bit. i fixed a typo,
added a bunch of helpful pointers (thanks to Paul Mundt and the linux/sh guys
for holding my hand :D), and improved a bunch of the error messages in the
test program
hope this helps
-mike
pgprYOnYyYAXF.pgp
Description: PGP signature
Fix typo when describing RTC_WKALM. Add some helpful pointers to people
developing their own RTC driver. Change a bunch of the error messages in the
test program to be a bit more helpful.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
index 7cf1ec5..1ef6bb8 100644
--- a/Documentation/rtc.txt
+++ b/Documentation/rtc.txt
@@ -149,7 +149,7 @@ RTC class framework, but can't be supported by the older driver.
is connected to an IRQ line, it can often issue an alarm IRQ up to
24 hours in the future.
-* RTC_WKALM_SET, RTC_WKALM_READ ... RTCs that can issue alarms beyond
+* RTC_WKALM_SET, RTC_WKALM_RD ... RTCs that can issue alarms beyond
the next 24 hours use a slightly more powerful API, which supports
setting the longer alarm time and enabling its IRQ using a single
request (using the same model as EFI firmware).
@@ -167,6 +167,28 @@ Linux out of a low power sleep state (or hibernation) back to a fully
operational state. For example, a system could enter a deep power saving
state until it's time to execute some scheduled tasks.
+Note that many of these ioctls need not actually be implemented by your
+driver. The common rtc-dev interface handles many of these nicely if your
+driver returns ENOIOCTLCMD. Some common examples:
+
+* RTC_RD_TIME, RTC_SET_TIME: the read_time/set_time functions will be
+ called with appropriate values.
+
+* RTC_ALM_SET, RTC_ALM_READ, RTC_WKALM_SET, RTC_WKALM_RD: the
+ set_alarm/read_alarm functions will be called. To differentiate
+ between the ALM and WKALM, check the larger fields of the rtc_wkalrm
+ struct (like tm_year). These will be set to -1 when using ALM and
+ will be set to proper values when using WKALM.
+
+* RTC_IRQP_SET, RTC_IRQP_READ: the irq_set_freq function will be called
+ to set the frequency while the framework will handle the read for you
+ since the frequency is stored in the irq_freq member of the rtc_device
+ structure. Also make sure you set the max_user_freq member in your
+ initialization routines so the framework can sanity check the user
+ input for you.
+
+If all else fails, check out the rtc-test.c driver!
+
8< 8< -
@@ -237,7 +259,7 @@ int main(int argc, char **argv)
"\n...Update IRQs not supported.\n");
goto test_READ;
}
- perror("ioctl");
+ perror("RTC_UIE_ON ioctl");
exit(errno);
}
@@ -284,7 +306,7 @@ int main(int argc, char **argv)
/* Turn off update interrupts */
retval = ioctl(fd, RTC_UIE_OFF, 0);
if (retval == -1) {
- perror("ioctl");
+ perror("RTC_UIE_OFF ioctl");
exit(errno);
}
@@ -292,7 +314,7 @@ test_READ:
/* Read the RTC time/date */
retval = ioctl(fd, RTC_RD_TIME, _tm);
if (retval == -1) {
- perror("ioctl");
+ perror("RTC_RD_TIME ioctl");
exit(errno);
}
@@ -320,14 +342,14 @@ test_READ:
"\n...Alarm IRQs not supported.\n");
goto test_PIE;
}
- perror("ioctl");
+ perror("RTC_ALM_SET ioctl");
exit(errno);
}
/* Read the current alarm settings */
retval = ioctl(fd, RTC_ALM_READ, _tm);
if (retval == -1) {
- perror("ioctl");
+ perror("RTC_ALM_READ ioctl");
exit(errno);
}
@@ -337,7 +359,7 @@ test_READ:
/* Enable alarm interrupts */
retval = ioctl(fd, RTC_AIE_ON, 0);
if (retval == -1) {
- perror("ioctl");
+ perror("RTC_AIE_ON ioctl");
exit(errno);
}
@@ -355,7 +377,7 @@ test_READ:
/* Disable alarm interrupts */
retval = ioctl(fd, RTC_AIE_OFF, 0);
if (retval == -1) {
- perror("ioctl");
+ perror("RTC_AIE_OFF ioctl");
exit(errno);
}
@@ -368,7 +390,7 @@ test_PIE:
fprintf(stderr, "\nNo periodic IRQ support\n");
return 0;
}
- perror("ioctl");
+ perror("RTC_IRQP_READ ioctl");
exit(errno);
}
fprintf(stderr, "\nPeriodic IRQ rate is %ldHz.\n", tmp);
@@ -387,7 +409,7 @@ test_PIE:
"\n...Periodic IRQ rate is fixed\n");
goto done;
}
- perror("ioctl");
+ perror("RTC_IRQP_SET ioctl");
exit(errno);
}
@@ -397,7 +419,7 @@ test_PIE:
/* Enable periodic interrupts */
retval = ioctl(fd, RTC_PIE_ON, 0);
if (retval == -1) {
- perror("ioctl");
+ perror("RTC_PIE_ON ioctl");
exit(errno);
}
@@ -416,7 +438,7 @@ test_PIE:
/* Disable periodic interrupts */
retval = ioctl(fd, RTC_PIE_OFF, 0);
if (retval == -1) {
- perror("ioctl");
+ perror("RTC_PIE_OFF ioctl");
exit(errno);
}
}
[PATCH] fix various kernel-doc in header files
From: Robert P. J. Day <[EMAIL PROTECTED]>
Fix a number of kernel-doc entries for header files in
include/linux by making sure they begin with the appropriate '/**'
notation and use @var notation.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
include/linux/bitops.h |6 ++
include/linux/list.h| 10 +-
include/linux/mutex.h |2 +-
include/linux/rtmutex.h |4 ++--
include/linux/timer.h |4 ++--
5 files changed, 12 insertions(+), 14 deletions(-)
--- linux-2620-rc4.orig/include/linux/bitops.h
+++ linux-2620-rc4/include/linux/bitops.h
@@ -31,9 +31,8 @@ static inline unsigned long hweight_long
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
}
-/*
+/**
* rol32 - rotate a 32-bit value left
- *
* @word: value to rotate
* @shift: bits to roll
*/
@@ -42,9 +41,8 @@ static inline __u32 rol32(__u32 word, un
return (word << shift) | (word >> (32 - shift));
}
-/*
+/**
* ror32 - rotate a 32-bit value right
- *
* @word: value to rotate
* @shift: bits to roll
*/
--- linux-2620-rc4.orig/include/linux/list.h
+++ linux-2620-rc4/include/linux/list.h
@@ -227,13 +227,13 @@ static inline void list_replace_init(str
INIT_LIST_HEAD(old);
}
-/*
+/**
* list_replace_rcu - replace old entry by new one
* @old : the element to be replaced
* @new : the new element to insert
*
- * The old entry will be replaced with the new entry atomically.
- * Note: 'old' should not be empty.
+ * The @old entry will be replaced with the @new entry atomically.
+ * Note: @old should not be empty.
*/
static inline void list_replace_rcu(struct list_head *old,
struct list_head *new)
@@ -680,12 +680,12 @@ static inline void hlist_del_init(struct
}
}
-/*
+/**
* hlist_replace_rcu - replace old entry by new one
* @old : the element to be replaced
* @new : the new element to insert
*
- * The old entry will be replaced with the new entry atomically.
+ * The @old entry will be replaced with the @new entry atomically.
*/
static inline void hlist_replace_rcu(struct hlist_node *old,
struct hlist_node *new)
--- linux-2620-rc4.orig/include/linux/mutex.h
+++ linux-2620-rc4/include/linux/mutex.h
@@ -105,7 +105,7 @@ do {
\
extern void __mutex_init(struct mutex *lock, const char *name,
struct lock_class_key *key);
-/***
+/**
* mutex_is_locked - is the mutex locked
* @lock: the mutex to be queried
*
--- linux-2620-rc4.orig/include/linux/rtmutex.h
+++ linux-2620-rc4/include/linux/rtmutex.h
@@ -16,7 +16,7 @@
#include
#include
-/*
+/**
* The rt_mutex structure
*
* @wait_lock: spinlock to protect the structure
@@ -71,7 +71,7 @@ struct hrtimer_sleeper;
#define DEFINE_RT_MUTEX(mutexname) \
struct rt_mutex mutexname = __RT_MUTEX_INITIALIZER(mutexname)
-/***
+/**
* rt_mutex_is_locked - is the mutex locked
* @lock: the mutex to be queried
*
--- linux-2620-rc4.orig/include/linux/timer.h
+++ linux-2620-rc4/include/linux/timer.h
@@ -41,7 +41,7 @@ static inline void setup_timer(struct ti
init_timer(timer);
}
-/***
+/**
* timer_pending - is a timer pending?
* @timer: the timer in question
*
@@ -63,7 +63,7 @@ extern int mod_timer(struct timer_list *
extern unsigned long next_timer_interrupt(void);
-/***
+/**
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
new rtc driver for Blackfin using rtc framework
i'm not looking to submit this as that'll be done with the rest of the
Blackfin stuff, i'm just looking for feedback from some bored people who know
the RTC framework :)
the attached driver implements full functionality for the Blackfin on-chip RTC
using the new RTC framework ... anyone mind giving it a quick look to see if
there's any obvious (or not obvious) errors ? thanks !
btw, the new RTC framework is pretty neat, kudos to all
-mike
pgpNzUQPcGYf9.pgp
Description: PGP signature
/*
* Blackfin On-Chip Real Time Clock Driver
* Supports BF531/BF532/BF533/BF534/BF536/BF537
*
* Copyright 2004-2007 Analog Devices Inc.
*
* Enter bugs at http://blackfin.uclinux.org/
*
* Licensed under the GPL-2 or later.
*/
/* The biggest issue we deal with in this driver is that register writes are
* synced to the RTC frequency of 1Hz. So if you write to a register and
* attempt to write again before the first write has completed, the new write
* is simply discarded. This can easily be troublesome if userspace disables
* one event (say periodic) and then right after enables an event (say alarm).
* Since all events are maintained in the same interrupt mask register, if
* we wrote to it to disable the first event and then wrote to it again to
* enable the second event, that second event would not be enabled as the
* write would be discarded and things quickly fall apart.
*
* To keep this delay from significantly degrading performance (we, in theory,
* would have to sleep for up to 1 second everytime we wanted to write a
* register), we only check the write pending status before we start to issue
* a new write. We bank on the idea that it doesnt matter when the sync
* happens so long as we don't attempt another write before it does. The only
* time userspace would take this penalty is when they try and do multiple
* operations right after another ... but in this case, they need to take the
* sync penalty, so we should be OK.
*
* Also note that the RTC_ISTAT register does not suffer this penalty; its
* writes to clear status registers complete immediately.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define stamp(fmt, args...) pr_debug("%s:%i: " fmt "\n", __FUNCTION__, __LINE__, ## args)
#define stampit() stamp("here i am")
struct bfin_rtc {
struct rtc_device *rtc_dev;
struct rtc_time rtc_alarm;
spinlock_t lock;
};
/* Bit values for the ISTAT / ICTL registers */
#define RTC_ISTAT_WRITE_COMPLETE 0x8000
#define RTC_ISTAT_WRITE_PENDING 0x4000
#define RTC_ISTAT_ALARM_DAY 0x0040
#define RTC_ISTAT_24HR0x0020
#define RTC_ISTAT_HOUR0x0010
#define RTC_ISTAT_MIN 0x0008
#define RTC_ISTAT_SEC 0x0004
#define RTC_ISTAT_ALARM 0x0002
#define RTC_ISTAT_STOPWATCH 0x0001
/* Shift values for RTC_STAT register */
#define DAY_BITS_OFF17
#define HOUR_BITS_OFF 12
#define MIN_BITS_OFF6
#define SEC_BITS_OFF0
/* Some helper functions to convert between the common RTC notion of time
* and the internal Blackfin notion that is stored in 32bits.
*/
static inline u32 rtc_time_to_bfin(unsigned long now)
{
u32 sec = (now % 60);
u32 min = (now % (60 * 60)) / 60;
u32 hour = (now % (60 * 60 * 24)) / (60 * 60);
u32 days = (now / (60 * 60 * 24));
return (sec << SEC_BITS_OFF) +
(min << MIN_BITS_OFF) +
(hour << HOUR_BITS_OFF) +
(days << DAY_BITS_OFF);
}
static inline unsigned long rtc_bfin_to_time(u32 rtc_bfin)
{
return (((rtc_bfin >> SEC_BITS_OFF) & 0x003F)) +
(((rtc_bfin >> MIN_BITS_OFF) & 0x003F) * 60) +
(((rtc_bfin >> HOUR_BITS_OFF) & 0x001F) * 60 * 60) +
(((rtc_bfin >> DAY_BITS_OFF) & 0x7FFF) * 60 * 60 * 24);
}
static inline void rtc_bfin_to_tm(u32 rtc_bfin, struct rtc_time *tm)
{
rtc_time_to_tm(rtc_bfin_to_time(rtc_bfin), tm);
}
/* Wait for the previous write to a RTC register to complete.
* Unfortunately, we can't sleep here as that introduces a race condition when
* turning on interrupt events. Consider this:
* - process sets alarm
* - process enables alarm
* - process sleeps while waiting for rtc write to sync
* - interrupt fires while process is sleeping
* - interrupt acks the event by writing to ISTAT
* - interrupt sets the WRITE PENDING bit
* - interrupt handler finishes
* - process wakes up, sees WRITE PENDING bit set, goes to sleep
* - interrupt fires while process is sleeping
* If anyone can point out the obvious solution here, i'm listening :). This
* shouldn't be an issue on an SMP or preempt system as this function should
* only be called with the rtc lock held.
*/
static void rtc_bfin_sync_pending(void)
{
stampit();
while (!(bfin_read_RTC_ISTAT() & RTC_ISTAT_WRITE_COMPLETE)) {
if (!(bfin_read_RTC_ISTAT() & RTC_ISTAT_WRITE_PENDING))
break;
}
bfin_write_RTC_ISTAT(RTC_ISTAT_WRITE_COMPLETE);
}
static void rtc_bfin_reset(struct bfin_rtc *rtc)
{
/*
RE: [RFC] [PATCH] Power S3 Resume Optimization Patch. Request for Comment
My initial idea was to execute only block device resume on the separate
thread, as it take almost 80% of the total device resume time ( I did
detailed profile of each device resume through rdtsc() counter) and rest
of them takes less than 20% in total( each device ( including char and
net)on its own takes less than 0.03 seconds). I could still save some
good amount of resume time ( apprx 1.2 sec). However Given this ratio,
and the fact that block device resume happening way at the end of the
list, I tried this with only taking care of Block devices.
I am not sure if there is a case where any scenario where Char
devices would take more resume time than normally it would. If so I can
modify the patch to put only block devices in separate thread for resume
Thanks
-hari
-Original Message-
From: Pavel Machek [mailto:[EMAIL PROTECTED]
Sent: Friday, January 19, 2007 3:00 PM
To: Seshadri, Harinarayanan
Cc: [EMAIL PROTECTED]; linux-acpi@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [RFC] [PATCH] Power S3 Resume Optimization Patch. Request
for Comment
Hi!
> [RFC][PATCH] Power S3 Resume optimisation
> Here is a simple patch for optimising the S3 resume. With this
> patch the resume time is 0.85. Given the fact that device
initialisation
> on the resume takes almost 70% of time, By executing the whole
> "device_resume()" function on a seperate kernel thread, the resume
gets
> completed( ie. the user can precieve) by ~0.85 sec.
Yep, but you also break it completely...
> To avoid any possible race condition while processing the IO
> request and to make sure all the io request are queued till the device
> resume thread exits, the IO schedulars (patched cfq and as) checks a
for
> system_resume flag, which is set when the device resume thread starts,
> if the flag is set, it doesnt put the request in the dispatch queue.
> Once the flag is cleared i.e when the device resume thread is
complete,
> the IO-schedular behave as in normal situation.
And you noticed that, so you fixed obvious problems on block devices.
Ignoring char and net devices completely.
> @@ -1088,6 +1088,19 @@
> if (list_empty(>fifo_list[adir]))
> return 0;
>
> + /*
> +* Check here for the System resume flag to be cleared, if
flag
> is
> + * still set the resume thread hasnt completed yet, and hence
> dont
> + * takeout any new request from the FIFO
> + */
> + extern int system_resuming;
> + if (system_resuming != 0)
> + {
Locking. CodingStyle.
> -static void suspend_finish(suspend_state_t state)
> +static int dev_resume_proc(void * data)
> {
> + /* Set the global resume flag, this will be checked by the
> IO_schedular
Broken mail client.
> + * before dispatching the IO request
> + */
> + system_resuming =1;
Add mdelay(1 hour) here. Then try to use your wifi card and your tv
grabber.
> device_resume();
> + system_resuming = 0;
> +#ifdef DEBUG
> + printk(" reseting system_resume \n");
> +#endif
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: High CPU usage with sata_nv
Hello, ris wrote: and dmesg Please report... 1. 'vmstat 1' result during file copy (w/ cpu 100%) 2. 'dmesg' result after file copy -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
Randy Dunlap wrote: On Sun, 21 Jan 2007 15:07:37 -0600 Jay Cliburn wrote: [snip] + value = ioread16(hw->hw_addr + REG_PCIE_CAP_LIST); + return ((value & 0xFF00) == 0x6C00) ? 0 : 1; Are there defines or enums for these? Fewer magic numbers would be nice/helpful/readable. [snip] + s32 ret; + ret = atl1_write_phy_reg(hw, 29, 0x0029); Fewer magic numbers? Unfortunately, we don't have a spec. This is how the vendor coded it. [snip] + +int enable_msi; +module_param(enable_msi, int, 0444); +MODULE_PARM_DESC(enable_msi, "Enable PCI MSI"); Hm, I thought that we didn't want individual drivers having MSI config options... Luca? This one was yours IIRC. Care to chime in? Randy, thank you for the review. Jay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Suspend to RAM generates oops and general protection fault
Hi. On Mon, 2007-01-22 at 13:34 +1100, Jean-Marc Valin wrote: > Hi, > > I just encountered the following oops and general protection fault > trying to suspend/resume my laptop. I've got a Dell D820 laptop with a 2 > GHz Core 2 Duo CPU. It usually suspends/resumes fine but not always. The > relevant errors are below but the full dmesg log is at > http://people.xiph.org/~jm/suspend_resume_oops.txt and my config is in > http://people.xiph.org/~jm/config-2.6.20-rc5.txt > > This happens when I'm running 2.6.20-rc5. The previous kernel version I > was using is 2.6.19-rc6 and was much more broken (second attempt > *always* failed), so it's probably not a regression. A second attempt always failing usually indicates that a driver was dazed and confused after the first cycle and properly killed by the second attempt, usually because of a lack of [proper] power management code. Between any two versions, some things can be fixed, some things can be broken and some things can become broken in different ways, so your different experience with 2.6.20-rc5 doesn't necessarily mean that this is a different issue. It looks like something is stomping on memory it shouldn't be touching, so I would suggest testing multiple cycles with a minimal (preferably zero) number of modules loaded. If that looks good and reliable, add modules & processes until you can say 'If I do X, it breaks.'. If having a minimal number of modules loaded doesn't help, I would then suggest reviewing your kernel config to see if other things can be built as modules and the same logic applied. You can be reasonably sure that it will be a device driver. Common causes of suspend/resume problems from the list you give below are acpi modules, bluetooth and usb. I'd also be consider pcmcia, drm and fuse possibilities. But again, go for unloading everything possible in the first instance. Regards, Nigel > Cheers, > > Jean-Marc > > P.S. This is the same laptop I had at LCA for which Linus told me to > disable preemption and try the newest rc version. > > [10746.449071] Unable to handle kernel NULL pointer dereference at > 0038 RIP: > [10746.449080] [] iput+0x18/0x80 > [10746.449092] PGD 3a607067 PUD 27b20067 PMD 0 > [10746.449099] Oops: [1] SMP > [10746.449104] CPU 0 > [10746.449107] Modules linked in: psmouse battery ac thermal fan button > ipw3945 ieee80211 tg3 arc4 ecb blkcipher ieee80211_crypt_wep > ieee80211_crypt binfmt_misc rfcomm l2cap bluetooth i915 drm > speedstep_centrino cpufreq_userspace cpufreq_powersave cpufreq_ondemand > cpufreq_stats freq_table cpufreq_conservative video sbs i2c_ec dock > asus_acpi backlight container ipv6 fuse sbp2 af_packet parport_pc lp > parport sg sr_mod cdrom snd_hda_intel snd_hda_codec tsdev snd_pcm_oss > snd_mixer_oss pcmcia snd_pcm snd_timer ata_generic snd shpchp > pci_hotplug soundcore snd_page_alloc serio_raw yenta_socket > rsrc_nonstatic pcmcia_core pcspkr evdev ext3 jbd mbcache ohci1394 > ehci_hcd ieee1394 ide_generic uhci_hcd usbcore generic sd_mod processor > [10746.449190] Pid: 218, comm: kswapd0 Not tainted 2.6.20-rc5-x86-64 #1 > [10746.449196] RIP: 0010:[] [] > iput+0x18/0x80 > [10746.449206] RSP: :810037f2dd50 EFLAGS: 00010283 > [10746.449212] RAX: RBX: 8103fcf0 RCX: > 8103fd20 > [10746.449219] RDX: 0001 RSI: 0286 RDI: > 8103fcf0 > [10746.449225] RBP: 0042 R08: R09: > > [10746.449232] R10: 28f5c28f5c28f5c3 R11: 8023ae90 R12: > > [10746.449239] R13: 810075721c70 R14: 805fa940 R15: > > [10746.449246] FS: () GS:8058e000() > knlGS: > [10746.449253] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > [10746.449259] CR2: 0038 CR3: 1207f000 CR4: > 06e0 > [10746.449265] Process kswapd0 (pid: 218, threadinfo 810037f2c000, > task 810037a1b760) > [10746.449269] Stack: 811ce2f0 802ddaf8 > 811ce3c0 811ce2f0 > [10746.449280] 0042 8022f645 810037f2dd80 > 0001cb60 > [10746.449288] 0090 81007daa0e00 00d0 > 802ddb49 > [10746.449296] Call Trace: > [10746.449305] [] prune_one_dentry+0x68/0xa0 > [10746.449314] [] prune_dcache+0x145/0x1e0 > [10746.449323] [] shrink_dcache_memory+0x19/0x50 > [10746.449331] [] shrink_slab+0x117/0x190 > [10746.449342] [] kswapd+0x382/0x4e0 > [10746.449356] [] autoremove_wake_function+0x0/0x30 > [10746.449370] [] kswapd+0x0/0x4e0 > [10746.449376] [] keventd_create_kthread+0x0/0x90 > [10746.449383] [] kthread+0xd9/0x120 > [10746.449394] [] child_rip+0xa/0x12 > [10746.449401] [] keventd_create_kthread+0x0/0x90 > [10746.449414] [] kthread+0x0/0x120 > [10746.449421] [] child_rip+0x0/0x12 > [10746.449426] > [10746.449429] > [10746.449430] Code: 48 8b 40 38 75 04 0f 0b eb fe 48 85 c0 74 0b 48 8b >
Suspend to RAM generates oops and general protection fault
Hi, I just encountered the following oops and general protection fault trying to suspend/resume my laptop. I've got a Dell D820 laptop with a 2 GHz Core 2 Duo CPU. It usually suspends/resumes fine but not always. The relevant errors are below but the full dmesg log is at http://people.xiph.org/~jm/suspend_resume_oops.txt and my config is in http://people.xiph.org/~jm/config-2.6.20-rc5.txt This happens when I'm running 2.6.20-rc5. The previous kernel version I was using is 2.6.19-rc6 and was much more broken (second attempt *always* failed), so it's probably not a regression. Cheers, Jean-Marc P.S. This is the same laptop I had at LCA for which Linus told me to disable preemption and try the newest rc version. [10746.449071] Unable to handle kernel NULL pointer dereference at 0038 RIP: [10746.449080] [] iput+0x18/0x80 [10746.449092] PGD 3a607067 PUD 27b20067 PMD 0 [10746.449099] Oops: [1] SMP [10746.449104] CPU 0 [10746.449107] Modules linked in: psmouse battery ac thermal fan button ipw3945 ieee80211 tg3 arc4 ecb blkcipher ieee80211_crypt_wep ieee80211_crypt binfmt_misc rfcomm l2cap bluetooth i915 drm speedstep_centrino cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_stats freq_table cpufreq_conservative video sbs i2c_ec dock asus_acpi backlight container ipv6 fuse sbp2 af_packet parport_pc lp parport sg sr_mod cdrom snd_hda_intel snd_hda_codec tsdev snd_pcm_oss snd_mixer_oss pcmcia snd_pcm snd_timer ata_generic snd shpchp pci_hotplug soundcore snd_page_alloc serio_raw yenta_socket rsrc_nonstatic pcmcia_core pcspkr evdev ext3 jbd mbcache ohci1394 ehci_hcd ieee1394 ide_generic uhci_hcd usbcore generic sd_mod processor [10746.449190] Pid: 218, comm: kswapd0 Not tainted 2.6.20-rc5-x86-64 #1 [10746.449196] RIP: 0010:[] [] iput+0x18/0x80 [10746.449206] RSP: :810037f2dd50 EFLAGS: 00010283 [10746.449212] RAX: RBX: 8103fcf0 RCX: 8103fd20 [10746.449219] RDX: 0001 RSI: 0286 RDI: 8103fcf0 [10746.449225] RBP: 0042 R08: R09: [10746.449232] R10: 28f5c28f5c28f5c3 R11: 8023ae90 R12: [10746.449239] R13: 810075721c70 R14: 805fa940 R15: [10746.449246] FS: () GS:8058e000() knlGS: [10746.449253] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [10746.449259] CR2: 0038 CR3: 1207f000 CR4: 06e0 [10746.449265] Process kswapd0 (pid: 218, threadinfo 810037f2c000, task 810037a1b760) [10746.449269] Stack: 811ce2f0 802ddaf8 811ce3c0 811ce2f0 [10746.449280] 0042 8022f645 810037f2dd80 0001cb60 [10746.449288] 0090 81007daa0e00 00d0 802ddb49 [10746.449296] Call Trace: [10746.449305] [] prune_one_dentry+0x68/0xa0 [10746.449314] [] prune_dcache+0x145/0x1e0 [10746.449323] [] shrink_dcache_memory+0x19/0x50 [10746.449331] [] shrink_slab+0x117/0x190 [10746.449342] [] kswapd+0x382/0x4e0 [10746.449356] [] autoremove_wake_function+0x0/0x30 [10746.449370] [] kswapd+0x0/0x4e0 [10746.449376] [] keventd_create_kthread+0x0/0x90 [10746.449383] [] kthread+0xd9/0x120 [10746.449394] [] child_rip+0xa/0x12 [10746.449401] [] keventd_create_kthread+0x0/0x90 [10746.449414] [] kthread+0x0/0x120 [10746.449421] [] child_rip+0x0/0x12 [10746.449426] [10746.449429] [10746.449430] Code: 48 8b 40 38 75 04 0f 0b eb fe 48 85 c0 74 0b 48 8b 40 28 48 [10746.449449] RIP [] iput+0x18/0x80 [10746.449456] RSP [10746.449460] CR2: 0038 [10746.449463] ACPI Exception (pci_bind-0299): AE_NOT_FOUND, Unable to get data from device DCKS [20060707] and later: [3.668009] SMP alternatives: switching to SMP code [3.668168] Booting processor 1/2 APIC 0x1 [4.149691] Initializing CPU#1 [4.229595] Calibrating delay using timer specific routine.. 3990.32 BogoMIPS (lpj=7980654) [4.229602] CPU: L1 I cache: 32K, L1 D cache: 32K [4.229604] CPU: L2 cache: 4096K [4.229606] CPU 1/1 -> Node 0 [4.229608] CPU: Physical Processor ID: 0 [4.229609] CPU: Processor Core ID: 1 [4.230107] Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping 06 [4.233607] CPU 1: Syncing TSC to CPU 0. [3.762970] CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 960 cycles) [3.764689] general protection fault: [2] SMP [3.764963] CPU 1 [3.764983] Modules linked in: psmouse battery ac thermal fan button arc4 ecb blkcipher ieee80211_crypt_wep ieee80211_crypt binfmt_misc rfcomm l2cap bluetooth i915 drm speedstep_centrino cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_stats freq_table cpufreq_conservative video sbs i2c_ec dock asus_acpi backlight container ipv6 fuse sbp2 af_packet parport_pc lp parport sg sr_mod cdrom snd_hda_intel snd_hda_codec tsdev snd_pcm_oss snd_mixer_oss pcmcia snd_pcm snd_timer
Re: SATA exceptions triggered by XFS (since 2.6.18)
Paolo Ornati wrote: I don't know. It's a two years old ST380817AS. # smartctl -a -d ata /dev/sda smartctl version 5.36 [x86_64-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family Device Model: ST380817AS I'll blacklist it. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
Hello, Chr wrote: Ok, you won't believe this... I opened my case and rewired my drives... And guess what, my second (aka the "good") HDD is now failing! I guess, my mainboard has a (but maybe two, or three :( ) "bad" sata-port(s)! Or, you have power related problem. Try to rewire the power lines or connect harddrives to a separate powersupply. It's often useful to change one component at a time and watch which change the problem follows. Anyways, you seem to be suffering transmission failures, not a driver problem. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
On Sun, 21 Jan 2007 15:07:37 -0600 Jay Cliburn wrote:
> This patch contains auxiliary C files for the Attansic L1 gigabit ethernet
> adapter driver.
>
> Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
> Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
> ---
>
> atl1_ethtool.c | 436 ++
> atl1_hw.c | 728
> +
> atl1_param.c | 223 +
> 3 files changed, 1387 insertions(+)
>
> diff --git a/drivers/net/atl1/atl1_ethtool.c b/drivers/net/atl1/atl1_ethtool.c
> new file mode 100644
> index 000..4c6e505
> --- /dev/null
> +++ b/drivers/net/atl1/atl1_ethtool.c
> @@ -0,0 +1,436 @@
> +/**
Please use "/**" _only_ to begin kernel-doc comments
(and this is not a kernel-doc comment).
(occurs at multiple other places in this and the other patches)
> + * Copyright(c) 2005 - 2006 Attansic Corporation. All rights reserved.
> + * Copyright(c) 2006 Chris Snook <[EMAIL PROTECTED]>
> + * Copyright(c) 2006 Jay Cliburn <[EMAIL PROTECTED]>
> + *
> + * Derived from Intel e1000 driver
> + * Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> with
> + * this program; if not, write to the Free Software Foundation, Inc., 59
> + * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + **/
> +
> +
> +static int atl1_get_settings(struct net_device *netdev, struct ethtool_cmd
> *ecmd)
> +{
> + struct atl1_adapter *adapter = netdev_priv(netdev);
> + struct atl1_hw *hw = >hw;
> +
> + ecmd->supported = (SUPPORTED_10baseT_Half |
> +SUPPORTED_10baseT_Full |
> +SUPPORTED_100baseT_Half |
> +SUPPORTED_100baseT_Full |
> +SUPPORTED_1000baseT_Full |
> +SUPPORTED_Autoneg | SUPPORTED_TP);
> + ecmd->advertising = ADVERTISED_TP;
> + if (hw->media_type == MEDIA_TYPE_AUTO_SENSOR ||
> + hw->media_type == MEDIA_TYPE_1000M_FULL) {
> + ecmd->advertising |= ADVERTISED_Autoneg;
> + if (hw->media_type == MEDIA_TYPE_AUTO_SENSOR) {
> + ecmd->advertising |= ADVERTISED_Autoneg;
> + ecmd->advertising |=
> + (ADVERTISED_10baseT_Half |
> + ADVERTISED_10baseT_Full |
> + ADVERTISED_100baseT_Half |
> + ADVERTISED_100baseT_Full |
> + ADVERTISED_1000baseT_Full);
> + } else {
> + ecmd->advertising |= (ADVERTISED_1000baseT_Full);
Kernel coding style is not to use braces around one-statement "blocks."
(occurs in multiple other places)
> + }
> + }
> + ecmd->port = PORT_TP;
> + ecmd->phy_address = 0;
> + ecmd->transceiver = XCVR_INTERNAL;
> +
> + if (netif_carrier_ok(adapter->netdev)) {
> + u16 link_speed, link_duplex;
> + atl1_get_speed_and_duplex(hw, _speed, _duplex);
> + ecmd->speed = link_speed;
> + if (link_duplex == FULL_DUPLEX)
> + ecmd->duplex = DUPLEX_FULL;
> + else
> + ecmd->duplex = DUPLEX_HALF;
> + } else {
> + ecmd->speed = -1;
> + ecmd->duplex = -1;
> + }
> + if (hw->media_type == MEDIA_TYPE_AUTO_SENSOR ||
> + hw->media_type == MEDIA_TYPE_1000M_FULL) {
> + ecmd->autoneg = AUTONEG_ENABLE;
> + } else {
> + ecmd->autoneg = AUTONEG_DISABLE;
> + }
> +
> + return 0;
> +}
> +
> +static int atl1_set_settings(struct net_device *netdev, struct ethtool_cmd
> *ecmd)
> +{
> + struct atl1_adapter *adapter = netdev_priv(netdev);
> + struct atl1_hw *hw = >hw;
> + u16 phy_data;
> + int ret_val = 0;
> + u16 old_media_type = hw->media_type;
> +
> + if (netif_running(adapter->netdev)) {
> + printk(KERN_DEBUG "%s: ethtool shutting down link adapter\n",
What's a "link adapter"?
> + atl1_driver_name);
> + atl1_down(adapter);
> + }
> +
> + if (ecmd->autoneg == AUTONEG_ENABLE) {
> + hw->media_type = MEDIA_TYPE_AUTO_SENSOR;
> + } else {
> + if (ecmd->speed == SPEED_1000) {
> + if (ecmd->duplex != DUPLEX_FULL) {
> +
Re: [PATCH] binfmt_elf: core dump masking support
Hi Pavel, The /proc// approach doesn't have these demerits, and it has an advantage that users can change the bitmask of any process at anytime. >>> >>>Well... not sure if it is advantage. >> >>For example, consider the following case: >> a process forks many children and system administrator wants to >> allow only one of these processes to dump shared memory. >> >>This is accomplished as follows: >> >> $ echo 1 > /proc/self/coremask >> $ ./some_program >> (fork children) >> $ echo 0 > /proc//coremask >> >>With the /proc// interface, we don't need to modify the >>user program. In contrast, with the ulimit or setrlimit interface, >>the administrator can't do it without modifying the user program >>to call setrlimit. This will not be preferred. > > Yep, otoh process coremask setting can change while it is running, > that is not expected. Hmm, it can also change while it is dumping > core, are you sure it is not racy? Good point, thanks. I never thought of that. We can change the coremask setting while dumping the process's memory, and it is problematic. maydump() function which decides a given VMA may be dumped or not is invoked twice per VMAs. One is at the time of writing a program header for a VMA, another is at the time of writing its contents. If the coremask setting differs between the two, the program header will point wrong place in the core file as its contents. > (run echo 1 > coremask, echo 0 > coremask in a loop while dumping > core. Do you have enough locking to make it work as expected?) Currently, any lock isn't acquired. But I think the kernel only have to preserve the coremask setting in a local variable at the begining of core dumping. I'm going to do this in the next version. Best regards, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc5] SPI: alternative fix for spi_busnum_to_master
On Thu, 18 Jan 2007 20:28:49 +0900 (JST), Atsushi Nemoto <[EMAIL PROTECTED]>
wrote:
> The commit was to fix spi_busnum_to_master(). Here is a patch fixes
> this function in other way, just searching children list of
> class_device.
Here is a revised version. The children list of spi_master_class
contains only spi_master class so we can just compare bus_num member
instead of class_id string.
Subject: SPI: alternative fix for spi_busnum_to_master
If a SPI master device exists, udev (udevtrigger) causes kernel crash,
due to wrong kobj pointer in kobject_uevent_env(). This problem was
not in 2.6.19.
The backtrace (on MIPS) was:
[<8024db6c>] kobject_uevent_env+0x54c/0x5e8
[<802a8264>] store_uevent+0x1c/0x3c (in drivers/class.c)
[<801cb14c>] subsys_attr_store+0x2c/0x50
[<801cb80c>] flush_write_buffer+0x38/0x5c
[<801cb900>] sysfs_write_file+0xd0/0x190
[<80181444>] vfs_write+0xc4/0x1a0
[<80181cdc>] sys_write+0x54/0xa0
[<8010dae4>] stack_done+0x20/0x3c
flush_write_buffer() passes kobject of spi_master_class.subsys to
subsys_addr_store(), then subsys_addr_store() passes a pointer to a
struct subsystem to store_uevent() which expects a pointer to a struct
class_device. The problem seems subsys_attr_store() called instead of
class_device_attr_store().
This mismatch was caused by commit
3bd0f6943520e459659d10f3282285e43d3990f1, which overrides kset of
master class. This made spi_master_class.subsys.kset.ktype NULL so
subsys_sysfs_ops is used instead of class_dev_sysfs_ops.
The commit was to fix spi_busnum_to_master(). Here is a patch fixes
this function in other way, just searching children list of
class_device.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 270e621..88c945b 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -366,7 +366,6 @@ spi_alloc_master(struct device *dev, uns
class_device_initialize(>cdev);
master->cdev.class = _master_class;
- kobj_set_kset_s(>cdev, spi_master_class.subsys);
master->cdev.dev = get_device(dev);
spi_master_set_devdata(master, [1]);
@@ -466,14 +465,22 @@ EXPORT_SYMBOL_GPL(spi_unregister_master)
*/
struct spi_master *spi_busnum_to_master(u16 bus_num)
{
- charname[9];
- struct kobject *bus;
-
- snprintf(name, sizeof name, "spi%u", bus_num);
- bus = kset_find_obj(_master_class.subsys.kset, name);
- if (bus)
- return container_of(bus, struct spi_master, cdev.kobj);
- return NULL;
+ struct class_device *cdev;
+ struct spi_master *master = NULL;
+
+ down(_master_class.sem);
+ list_for_each_entry(cdev, _master_class.children, node) {
+ cdev = class_device_get(cdev);
+ if (!cdev)
+ continue;
+ master = container_of(cdev, struct spi_master, cdev);
+ if (master->bus_num == bus_num)
+ break;
+ master = NULL;
+ class_device_put(cdev);
+ }
+ up(_master_class.sem);
+ return master;
}
EXPORT_SYMBOL_GPL(spi_busnum_to_master);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
Jan Engelhardt <[EMAIL PROTECTED]> writes: > Bleh. Except for storage, base 1024 was used for almost everything > I remember. 4 MB memory meant 4096 KB, and that's still the case today. > Most likely the same for transfer rates. Nope, transfer rates were initially 1000-based: 9.6 kbps = 9600 bps, 28.8 kbps = 28800 bps, 64 kbps = 64000 bps. Then it went 128, 256, 512 kbps = 512000 bps and 1 Mbps = 2 * 512 kbps = 1024000 bps. But it's limited mostly to serial interfaces. Other networks use 10, 1000 etc. because they have nothing natural in (powers of) 2 so 1 Mbps may be 100 bps as well. > It's just that storage vendors broke the computer rule and went with 1000. 1024 etc. is (should be) natural to disks because the sector size is 512 B, 2048 B or something like that. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Undo some of the pseudo-security madness
At Sun, 21 Jan 2007 19:36:27 -0500, Kyle Moffett wrote: > > On Jan 21, 2007, at 18:34:56, David Wagner wrote: > > [1] In comparison, suidperl was designed to be installed setuid- > > root, and it takes special precautions to be safe in this usage. > > (And even it has had some security vulnerabilities, despite its > > best efforts, which illustrates how tricky this business can be.) > > Setting the setuid-root bit on a large complex interpreter that > > wasn't designed to be setuid-root seems like a pretty dubious > > proposition to me. > > Well, there's also the fact that Linux does *NOT* need suidperl, as > it has proper secure support for suid pound-bang scripts anyways. > The only reason for suidperl in the first place was broken operating > systems which had a race condition between the operating system > checking the suid bits and reading the '#! /usr/bin/perl' line in the > file, and the interpreter getting executed and opening a different > file (think symlink redirection attacks). I believe Linux jumps > through some special hoops to ensure that can't happen. Uh, this does not work, unfortunately in the Lisp case. Lisp environments can produce standalone executables, which are 1. supposed to be runnable like a usual binary, without any additions 2. will suffer from the very same problem, as it merely is a runtime bundled with the core file (and the core file is unrelocatable) > Kyle Moffett regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT question
Hello everyone, This is a long thread about O_DIRECT surprisingly without a single bugreport in it, that's a good sign that O_DIRECT is starting to work well in 2.6 too ;) On Fri, Jan 12, 2007 at 02:47:48PM -0800, Andrew Morton wrote: > On Fri, 12 Jan 2007 15:35:09 -0700 > Erik Andersen <[EMAIL PROTECTED]> wrote: > > > On Fri Jan 12, 2007 at 05:09:09PM -0500, Linus Torvalds wrote: > > > I suspect a lot of people actually have other reasons to avoid caches. > > > > > > For example, the reason to do O_DIRECT may well not be that you want to > > > avoid caching per se, but simply because you want to limit page cache > > > activity. In which case O_DIRECT "works", but it's really the wrong thing > > > to do. We could export other ways to do what people ACTUALLY want, that > > > doesn't have the downsides. > > > > I was rather fond of the old O_STREAMING patch by Robert Love, > > That was an akpmpatch whcih I did for the Digeo kernel. Robert picked it > up to dehackify it and get it into mainline, but we ended up deciding that > posix_fadvise() was the way to go because it's standards-based. > > It's a bit more work in the app to use posix_fadvise() well. But the > results will be better. The app should also use sync_file_range() > intelligently to control its pagecache use. > > The problem with all of these things is that the application needs to be > changed, and people often cannot do that. If we want a general way of And if the application needs to be changed then IMHO it sounds better to go the last mile and to use O_DIRECT instead of O_STREAMING to run in zerocopy. Benchmarks have been posted here as well to show what a kind of difference O_DIRECT can make. O_STREAMING really shouldn't exist and all O_STREAMING users should be converted to O_DIRECT. The only reason O_DIRECT exists is to bypass the pagecache and to run in zerocopy, to avoid all pagecache lookups and locking, to preserve cpu caches, to avoid losing smp scalability in the memory bus in not-numa systems, and to avoid the general cpu overhead of copying the data with the cpu for no good reason. The cache polluting avoidance that O_STREAMING and fadvise can also provide, is an almost not interesting feature. I'm afraid databases aren't totally stupid here using O_DIRECT, the caches they keep in ram isn't necessarily always a 1:1 mapping of the on-disk data, so replacing O_DIRECT with a MAP_SHARED of the source file, wouldn't be the best even if they could be convinced to trust the OS instead of insisting to bypass it (and if they could combine MAP_SHARED with asyncio somehow). They don't have problems to trust the OS when they map tmpfs as MAP_SHARED after all... Why to waste time copying the data through pagecache if the pagecache itself won't be useful when the db is properly tuned? Linus may be right that perhaps one day the CPU will be so much faster than disk that such a copy will not be measurable and then O_DIRECT could be downgraded to O_STREAMING or an fadvise. If such a day will come by, probably that same day Dr. Tanenbaum will be finally right about his OS design too. Storage speed is growing along cpu speeds, especially with contiguous I/O and by using fast raid storage, so I don't see it very likely that we can ignore those memory copies any time soon. Perhaps an average amd64 desktop system with a single sata disk may never get a real benefit from O_DIRECT compared to O_STREAMING, but that's not the point as linux doesn't only run on desktops with a single SATA disk running at only 50M/sec (and abysmal performance while seeking). With regard to the locking mess, O_DIRECT already fallback to buffered mode while creating new blocks and uses proper locking to serialize against i_size changes (by sct). filling holes and i_size changes are the forbidden sins of O_DIRECT. The rest is just a matter of cache invalidates or cache flushes run at the right time. With more recent 2.6 changes, even further complexity has been introduced to allow mapped cache to see O_DIRECT writes, I've never been convinced that this was really useful. There was nothing wrong in having a not uptodate page mapped in userland (except to workaround an artifical BUG_ON that tried to enforce that artificial invariant for no apparent required reason), but it should work ok and it can be seen as a new feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
"Horst H. von Brand" <[EMAIL PROTECTED]> writes: > Junio C Hamano <[EMAIL PROTECTED]> wrote: >> Willy Tarreau <[EMAIL PROTECTED]> writes: >> > Anything you can do to make tester's life easier will always slightly >> > increase the number of testers. >> > ... >> > Pre-release tar.gz and rpms coupled with a freshmeat announcement should >> > get you a bunch of testers and newcomers. This will give the new doc a >> > real trial, and will help discover traps in which beginners often fall. >> >> One worry I had about releasing git-1.5.0-rc2-1.rpm and friends >> just like the "official" ones was that people might have scripts >> to automate downloading & updating of packages, and they may not >> like to get "beta" installed for them. > > Then put them into a "testing" or "pre-release" directory... Ok, thanks for the suggestion. The preview RPMs for i386 and x86_64 and an SRPM are available at: /pub/software/scm/git/testing/ The tarball for 1.5.0-rc2 is found at: /pub/software/scm/git/git-1.5.0.rc2.tar.gz along with tarballs of preformatted htmldocs and manpages. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Another possible dumb question re usb
Greetings; I am attempting to get into a wap11 radio through its usb port, because that port offers a way to restore factory defaults and in the year its been quiet, I've forgotten the uname/pw. To access it with snmp over cat5, the uname & pw are a requirement. I have rebuilt the 2.6.20-rc4 kernel with every usb or pci network related item I can find that looks as if it might have something to do with this radio, which an lsusb reports as: Bus 002 Device 006: ID 03eb:5601 Atmel Corp. at76c510 Prism-II 802.11b Access Point Did I miss something, or is this going to need a trip to a windows box to fix? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc4-mm1 aio bug
Hi,
I get this while running aiostress.
Jan 22 01:50:05 black-mamba kernel:
===
Jan 22 01:50:05 black-mamba kernel: [ INFO: possible circular locking
dependency detected ]
Jan 22 01:50:05 black-mamba kernel: 2.6.20-rc4-mm1 #1
Jan 22 01:50:05 black-mamba kernel:
---
Jan 22 01:50:05 black-mamba kernel: aio/1/206 is trying to acquire lock:
Jan 22 01:50:05 black-mamba kernel: (>lock){++..}, at: []
__wake_up+0x15/0x42
Jan 22 01:50:05 black-mamba kernel:
Jan 22 01:50:05 black-mamba kernel: but task is already holding lock:
Jan 22 01:50:05 black-mamba kernel: (>ctx_lock){.+..}, at: []
aio_complete+0x66/0x17d
Jan 22 01:50:05 black-mamba kernel:
Jan 22 01:50:05 black-mamba kernel: which lock already depends on the new lock.
Jan 22 01:50:05 black-mamba kernel:
Jan 22 01:50:06 black-mamba kernel:
Jan 22 01:50:06 black-mamba kernel: the existing dependency chain (in reverse
order) is:
Jan 22 01:50:06 black-mamba kernel:
Jan 22 01:50:06 black-mamba kernel: -> #1 (>ctx_lock){.+..}:
Jan 22 01:50:06 black-mamba kernel:[]
__lock_acquire+0xb07/0xccd
Jan 22 01:50:06 black-mamba kernel:[] lock_acquire+0x79/0x93
Jan 22 01:50:06 black-mamba kernel:[]
_spin_lock_irqsave+0x3e/0x4e
Jan 22 01:50:06 black-mamba kernel:[] kick_iocb+0x4f/0xb4
Jan 22 01:50:06 black-mamba kernel:[]
aio_wake_function+0x44/0x49
Jan 22 01:50:06 black-mamba kernel:[]
__wake_up_common+0x32/0x55
Jan 22 01:50:06 black-mamba kernel:[] __wake_up+0x31/0x42
Jan 22 01:50:06 black-mamba kernel:[] __wake_up_bit+0x2e/0x34
Jan 22 01:50:06 black-mamba kernel:[] unlock_page+0x25/0x28
Jan 22 01:50:06 black-mamba kernel:[]
mpage_end_io_read+0x55/0x6a
Jan 22 01:50:06 black-mamba kernel:[] bio_endio+0x6c/0x74
Jan 22 01:50:06 black-mamba kernel:[]
__end_that_request_first+0x212/0x498
Jan 22 01:50:06 black-mamba kernel:[]
end_that_request_chunk+0x8/0xa
Jan 22 01:50:06 black-mamba kernel:[]
scsi_end_request+0x20/0xb1
Jan 22 01:50:06 black-mamba kernel:[]
scsi_io_completion+0xff/0x2d6
Jan 22 01:50:06 black-mamba kernel:[] sd_rw_intr+0x17b/0x1a7
Jan 22 01:50:06 black-mamba kernel:[]
scsi_finish_command+0x45/0x4a
Jan 22 01:50:06 black-mamba kernel:[]
scsi_softirq_done+0xb1/0xb9
Jan 22 01:50:06 black-mamba kernel:[]
blk_done_softirq+0x59/0x68
Jan 22 01:50:06 black-mamba kernel:[] __do_softirq+0x6d/0xea
Jan 22 01:50:06 black-mamba kernel:[] do_softirq+0x39/0x55
Jan 22 01:50:06 black-mamba kernel:[] irq_exit+0x46/0x53
Jan 22 01:50:06 black-mamba kernel:[] do_IRQ+0xad/0xc1
Jan 22 01:50:06 black-mamba kernel:[]
common_interrupt+0x2e/0x34
Jan 22 01:50:06 black-mamba kernel:[]
cache_alloc_debugcheck_after+0x33/0x15c
Jan 22 01:50:06 black-mamba kernel:[]
kmem_cache_alloc+0xb3/0xbf
Jan 22 01:50:06 black-mamba kernel:[]
mempool_alloc_slab+0xe/0x10
Jan 22 01:50:06 black-mamba kernel:[] mempool_alloc+0x35/0xf2
Jan 22 01:50:06 black-mamba kernel:[] get_request+0x13b/0x2ee
Jan 22 01:50:06 black-mamba kernel:[]
get_request_wait+0x26/0x17e
Jan 22 01:50:06 black-mamba kernel:[]
__make_request+0x17f/0x2a7
Jan 22 01:50:06 black-mamba kernel:[]
generic_make_request+0x2e1/0x30f
Jan 22 01:50:06 black-mamba kernel:[] submit_bio+0x132/0x13a
Jan 22 01:50:06 black-mamba kernel:[]
mpage_bio_submit+0x1c/0x21
Jan 22 01:50:06 black-mamba kernel:[]
mpage_readpages+0x122/0x130
Jan 22 01:50:06 black-mamba kernel:[] ext3_readpages+0x19/0x1b
Jan 22 01:50:06 black-mamba kernel:[]
__do_page_cache_readahead+0x13a/0x1ec
Jan 22 01:50:06 black-mamba kernel:[]
page_cache_readahead_adaptive+0x468/0x4de
Jan 22 01:50:06 black-mamba kernel:[]
do_generic_mapping_read+0x1e5/0x568
Jan 22 01:50:06 black-mamba kernel:[]
generic_file_aio_read+0x19a/0x1c8
Jan 22 01:50:06 black-mamba kernel:[]
aio_rw_vect_retry+0x6a/0x129
Jan 22 01:50:06 black-mamba kernel:[] aio_run_iocb+0xbf/0x164
Jan 22 01:50:06 black-mamba kernel:[]
io_submit_one+0x3f1/0x43c
Jan 22 01:50:06 black-mamba kernel:[] sys_io_submit+0xe3/0x16e
Jan 22 01:50:06 black-mamba kernel:[] syscall_call+0x7/0xb
Jan 22 01:50:06 black-mamba kernel:[] 0x
Jan 22 01:50:06 black-mamba kernel:
Jan 22 01:50:06 black-mamba kernel: -> #0 (>lock){++..}:
Jan 22 01:50:06 black-mamba kernel:[]
__lock_acquire+0x9eb/0xccd
Jan 22 01:50:06 black-mamba kernel:[] lock_acquire+0x79/0x93
Jan 22 01:50:07 black-mamba kernel:[]
_spin_lock_irqsave+0x3e/0x4e
Jan 22 01:50:07 black-mamba kernel:[] __wake_up+0x15/0x42
Jan 22 01:50:07 black-mamba kernel:[] aio_complete+0x168/0x17d
Jan 22 01:50:07 black-mamba kernel:[] aio_run_iocb+0x103/0x164
Jan 22
Re: [PATCH] Undo some of the pseudo-security madness
At Mon, 22 Jan 2007 01:35:46 +0100, Arjan van de Ven wrote: > > the core of the problem are the cores which are customarily > > dumped by lisps during the environment generation (or modification) stage, > > and then mapped back, every time the environment is invoked. > > > > > at the current step of evolution, those core files are not relocatable > > in certain natively compiling lisp systems. > > nor will they work if the sysadmin applies a security update and glibc > or another library changes one page in size. Or changes the stack rlimit > or .. or .. At this point i should just step down and declare incompetence -- SBCL works around shlib size variance, somehow, and /yet/ the whole turn-off-AS-randomisation-and-reexec-self thing is still present in the source, for some reason. I should let more competent people (read, the actual SBCL developers) take the way from now... (I could have digged the source myself, but it is way too late today. However, if nobody from the development team answers by tomorrow`s evening (gmt+3), i should see into the thing for myself). > -- > if you want to mail me at work (you don't), use arjan (at) linux.intel.com > Test the interaction between Linux and your BIOS via > http://www.linuxfirmwarekit.org regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
i_ino 4 billion file limitation
I am now pushing up against the i_ino (unsigned long) file limitation when I use virtual inode numbers in DSFS. This field needs to be increased to 64 bit to allow more than 4 billion unique inode numbers. I am running out of inode address space with the current architecture. 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/
[RFC 0/6] bidi support: block, SCSI, and iSCSI layers
Following are 6 (large) patches that introduce support
for bidirectional requests in the kernel.
Since all this is going to interfere with everyone's
work, let us all comment on the implementation, naming,
and future directions. (or forever hold your peace).
The submitted work is against linux-2.6-block tree of
2007/01/15. It compiles with make allmodconfig in both
i386 and x86_64, and it boots and runs on my x86_64
test machines. The target kernel is able to compile a
Linux-kernel, burn and read cd, and pass iSCSI and OSD
tests. OSD tests are the ones who exercise BIDI I/O.
Patches summary:
1. data direction
- add support for enum dma_data_direction in struct request
in preparation to full bidi support.
- removed rq_data_dir() and added other APIs for querying request's
direction.
- fix usage of rq_data_dir() and peeking at req->cmd_flags & REQ_RW to
using
new api.
- clean-up bad usage of DMA_BIDIRECTIONAL and bzero of "black" requests,
to use the new blk_rq_init_unqueued_req()
2. request_io_part
- extract io related fields in struct request into struct
request_io_part
in preparation to full bidi support.
- use new API for accessing the new sub-structure
3. bidi request
- add one more request_io_part member for bidi support in struct
request.
- add block layer API functions for mapping and accessing bidi data
buffers
and for ending a block request as a whole (end_that_request_block())
4. bidi-scsi
- add bidi support at the scsi layer
- new scsi api functions to generate bidi capable requests
(scsi_execute_bidi{,_async})
- new scsi api for accessing scsi_cmnd_buff (similar to request_io_part
but not yet implemented as a sub-structure)
5. varlen cdb
- add support for variable length (or just longer than 16 bytes) SCSI
CDBs
- add scsi device type for OSD devices (will be separated in actual
patchset)
6. iscsi bidi varlen
- add support for bidi and variable length commands at the iscsi layer
for the tcp transport. (will also be separated and sent through the
open-iscsi project)
Developer comments: (long, can be skipped)
1. This part borrows from struct scsi_cmnd use of an enum dma_data_direction
member, to keep
everything the same.
1.A. It could be done in a more backward compatible way but it was a good
chance for some clean-up
(see the mess with BIO flags that used to be the same but no longer are). I
also believe
that two ways to describe the same thing will always come to haunt you later.
1.B. Speaking of which, the PCI_DMA_XXX constants are a pain being the same
constants but #defined and
untyped. It confused me in my bidi-bug hunting and it seems I'm not the only
one.
I would suggest boldly inverting enum dma_data_direction from its active-low
DMA logic and
change its name to just enum data_direction. Then, define the PCI_DMA_XXX
constants as a new enum,
and accept that new enum at all the dma_XXX mapping APIs, instead of the
current u32. Note
that this is cardinal now because bidirectional means __different_things__ in
struct request
and in DMA (or memory) mapping. the first means bidirectional access to
__same__ buffer, the later
means __two_sets__ of buffers at one request. (each buffer mapped for
uni-directional access).
2. Separation of IO members into two sub structures: There are 2 possible
approaches here and each approach
can have a few implementations.
2.A. First approach is to keep everything backward compatible and have a bidi
sub-structure on the side.
This approach can be seen in the attached patch for bidi support in SCSI
layer. It keeps the patch to
a minimum but is hell on readability & maintenance. It also puts a
performance penalty on users like iscsi
who wants to use a generic bidi-api.
2.B. Second approach is what is seen here. Separate all I/O members to a
sub-structure, craft an
API to access each part and a UNI api that wants to access buffers knowing
they are uni-
directional.
3.C. The second approach can be implemented as I did it: one member for
uni/bidi-write and second
for bidi-read or alternatively, using one sub-structure for "read" and
another for "write". I hope
I have built it in such a way that this choice is merely an "implementation
detail" only concerning
the block layer and hidden behind proper access functions.
3.D. I have currently decided on the first approach for performance reasons,
since 99.99% of kernel
is uni-directional (only exception is proposed iscsi). What will be in the
future? I'm not sure,
If most bus protocols are like iSCSI (and SCSI) where there is a clear
separation, and concurrency,
between write and read states. then second approach will be the logical
choice. Or maybe it is
Re: [PATCH] Undo some of the pseudo-security madness
David Wagner wrote: > Samium Gromoff wrote: > >[...] directly setuid root the lisp system executable itself [...] > > Like I said, that sounds like a bad idea to me. Sounds like a recipe for > privilege escalation vulnerabilities. Was the lisp system executable > really implemented to be secure even when you make it setuid root? > Setting the setuid-root bit on programs that didn't expect to be > setuid-root is generally not a very safe thing to do. [1] 1. Unsafe setuid programs have been written, and they doubtlessly will continue to be written. 2. Lisp systems are written by extremely competent people. (who make mistakes nonetheless, but still..) 3. I think that the ability to choose whether or not to shoot oneself in the foot is an important freedom. 4. The whole issue is a little bit unfair, because the UNIX world is inherently C-centric -- everything outside the C niche does not, indeed, fit flawlessly in the picture.. This is where the "if you want to write system software, do it in C" model comes from. 5. If a killer use-case is needed, an X server might do -- these need root privileges for a certain period. What if i decide that i want to write one in Lisp? > The more I hear, the more unconvinced I am by this use case. > > If you don't care about the security issues created by (mis)using the lisp > interpreter in this way, then like I suggested before, you can always ^^^ make that a compiler -- these days, probably, there are more native-bytecode-generating lisp compilers than interpreters. > write a tiny setuid-root wrapper program that turns off address space > randomization and exec()s the lisp system executable, and leave the lisp > system executable non-setuid and don't touch the code in the Linux kernel. > That strikes me as a better solution: those who don't mind the security > risks can take all the risks they want, without forcing others to take > unwanted and unnecessary risks. This might sound as a reasonable solution. Although it places a certain burden, which has to be considered... I should see what the SBCL people will say about that. > It's not that I'm wedded to address space randomization of setuid > programs, or that I think it would be a disaster if this patch were > accepted. Local privilege escalation attacks aren't the end of the world; > in all honesty, they're pretty much irrelevant to many or most users. > It's just that the arguments I'm hearing advanced in support of this > change seem dubious, and the change does eliminate one of the defenses > against a certain (narrow) class of attacks. > > > [1] In comparison, suidperl was designed to be installed setuid-root, > and it takes special precautions to be safe in this usage. (And even it > has had some security vulnerabilities, despite its best efforts, which > illustrates how tricky this business can be.) Setting the setuid-root > bit on a large complex interpreter that wasn't designed to be setuid-root > seems like a pretty dubious proposition to me. Compiler, not interpreter, careful with the insults :-) regards, Samium Gromoff P.S. please cc me, as i am not subscribed to the list... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions triggered by XFS (since 2.6.18)
Chr wrote: >> 7 Seek_Error_Rate 0x000f 083 060 030Pre-fail Always >> - 204305750 >> 1 Raw_Read_Error_Rate 0x000f 059 049 006Pre-fail Always >> - 215927244 >> 195 Hardware_ECC_Recovered 0x001a 059 049 000Old_age Always >> - 215927244 > > Wow! that HDD is really in a bad condition. I don't think so, this seems to be normal for Seagate drives... regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OnStream DI30: undescriptive message: CoD != 0 in idescsi_pc_intr
On Sun, 21 Jan 2007 03:14:33 +0100 Bauke Jan Douma wrote:
> OnStream Di30 (using ide-scsi and osst drivers), when reading
> or writing I regularly get these kernel messages:
>
> <3>ide-scsi: CoD != 0 in idescsi_pc_intr
>
> Let's assume flaky hardware; nothing we can hold the kernel to
> blame for (which is 2.6.19.1) -- it's a good thing it's calling
> our attention. There's no data corruption, btw.
>
> However, said message is quite useless because undescriptive
> and too terse.
Not sure that this helps much.
---
From: Randy Dunlap <[EMAIL PROTECTED]>
Expand on a terse ide-scsi message.
Something is confused.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/scsi/ide-scsi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2619-work.orig/drivers/scsi/ide-scsi.c
+++ linux-2619-work/drivers/scsi/ide-scsi.c
@@ -528,7 +528,7 @@ static ide_startstop_t idescsi_pc_intr (
ireason.all = HWIF(drive)->INB(IDE_IREASON_REG);
if (ireason.b.cod) {
- printk(KERN_ERR "ide-scsi: CoD != 0 in idescsi_pc_intr\n");
+ printk(KERN_ERR "ide-scsi: CoD(Command/Data flag) != 0(Data) in
idescsi_pc_intr\n");
return ide_do_reset (drive);
}
if (ireason.b.io) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Undo some of the pseudo-security madness
On Jan 21, 2007, at 18:34:56, David Wagner wrote: [1] In comparison, suidperl was designed to be installed setuid- root, and it takes special precautions to be safe in this usage. (And even it has had some security vulnerabilities, despite its best efforts, which illustrates how tricky this business can be.) Setting the setuid-root bit on a large complex interpreter that wasn't designed to be setuid-root seems like a pretty dubious proposition to me. Well, there's also the fact that Linux does *NOT* need suidperl, as it has proper secure support for suid pound-bang scripts anyways. The only reason for suidperl in the first place was broken operating systems which had a race condition between the operating system checking the suid bits and reading the '#! /usr/bin/perl' line in the file, and the interpreter getting executed and opening a different file (think symlink redirection attacks). I believe Linux jumps through some special hoops to ensure that can't happen. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Undo some of the pseudo-security madness
> the core of the problem are the cores which are customarily > dumped by lisps during the environment generation (or modification) stage, > and then mapped back, every time the environment is invoked. > > at the current step of evolution, those core files are not relocatable > in certain natively compiling lisp systems. nor will they work if the sysadmin applies a security update and glibc or another library changes one page in size. Or changes the stack rlimit or .. or .. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] bidi support: request dma_data_direction
Boaz Harrosh wrote: > - Introduce a new enum dma_data_direction data_dir member in struct request. > and remove the RW bit from request->cmd_flag > - Add new API to query request direction. > - Adjust existing API and implementation. > - Cleanup wrong use of DMA_BIDIRECTIONAL > - Introduce new blk_rq_init_unqueued_req() and use it in places ad-hoc > requests were used and bzero'ed. With a bi-directional transfer is it always unambiguous which transfer occurs first (or could they occur at the same time)? Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
Björn Steinbrink wrote: On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: Björn Steinbrink wrote: All kernels were bad using that approach. So back to square 1. :/ Björn OK guys, here's a new patch to try against 2.6.20-rc5: Right now when switching between ADMA mode and legacy mode (i.e. when going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just set the ADMA GO register bit appropriately and continue with no delay. It looks like in some cases the controller doesn't respond to this immediately, it takes some nanoseconds for the controller's status registers to reflect the change that was made. It's possible that if we were trying to issue commands during this time, the controller might not react properly. This patch adds some code to wait for the status register to change to the state we asked for before continuing. Just got two exceptions with your patch, none of the debug messages were issued. Björn Hmm, another miss, apparently.. Has anyone tried removing these lines from nv_host_intr in 2.6.20-rc5 sata_nv.c and see what that does? /* bail out if not our interrupt */ if (!(irq_stat & NV_INT_DEV)) return 0; -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
Samium Gromoff wrote: >[...] directly setuid root the lisp system executable itself [...] Like I said, that sounds like a bad idea to me. Sounds like a recipe for privilege escalation vulnerabilities. Was the lisp system executable really implemented to be secure even when you make it setuid root? Setting the setuid-root bit on programs that didn't expect to be setuid-root is generally not a very safe thing to do. [1] The more I hear, the more unconvinced I am by this use case. If you don't care about the security issues created by (mis)using the lisp interpreter in this way, then like I suggested before, you can always write a tiny setuid-root wrapper program that turns off address space randomization and exec()s the lisp system executable, and leave the lisp system executable non-setuid and don't touch the code in the Linux kernel. That strikes me as a better solution: those who don't mind the security risks can take all the risks they want, without forcing others to take unwanted and unnecessary risks. It's not that I'm wedded to address space randomization of setuid programs, or that I think it would be a disaster if this patch were accepted. Local privilege escalation attacks aren't the end of the world; in all honesty, they're pretty much irrelevant to many or most users. It's just that the arguments I'm hearing advanced in support of this change seem dubious, and the change does eliminate one of the defenses against a certain (narrow) class of attacks. [1] In comparison, suidperl was designed to be installed setuid-root, and it takes special precautions to be safe in this usage. (And even it has had some security vulnerabilities, despite its best efforts, which illustrates how tricky this business can be.) Setting the setuid-root bit on a large complex interpreter that wasn't designed to be setuid-root seems like a pretty dubious proposition to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problems with latest smbfs changes on 2.4.34 and security backports
On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote: >Hi Grant ! > >On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote: >> On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote: >> >> >On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote: >> >Ah, think I see the problem now: >> > >> >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 >> >17:53:57.247695476 -0700 >> >+++ kernel-source-2.4.27/fs/smbfs/proc.c2007-01-19 17:49:07.480161733 >> >-0700 >> >@@ -1997,7 +1997,7 @@ >> >fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | >> > S_IRWXO)) | S_IFDIR; >> >else if ( (server->mnt->flags & SMB_MOUNT_FMODE) && >> > !(S_ISDIR(fattr->f_mode)) ) >> >- fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | >> >S_IRWXO)) | S_IFREG; >> >+ fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | >> >S_IRWXO)) | (fattr->f_mode & S_IFMT); >> > >> > } >> > >> client running 2.4.34 with above patch, server is running 2.6.19.2 to >> eliminate it from the problem space (hopefully ;) : >> [EMAIL PROTECTED]:/home/other$ uname -r >> 2.4.34b >> [EMAIL PROTECTED]:/home/other$ ls -l >> total 9 >> drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/ >> drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/ >> -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file* >> -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 filelink* > >It seems to me that there is a difference, because filelink now appears the >same size as file. It's just as if we had hard links instead of symlinks. Hi Willy, No, those dir and files were created server-side, sorry I gave wrong impression, I still get on client side: [EMAIL PROTECTED]:/home/other$ uname -r 2.4.34b [EMAIL PROTECTED]:/home/other$ mkdir test [EMAIL PROTECTED]:/home/other$ ln -s test testlink ln: creating symbolic link `testlink' to `test': Operation not permitted [EMAIL PROTECTED]:/home/other$ echo "this is also a test" > test/file [EMAIL PROTECTED]:/home/other$ ln -s test/file test2 ln: creating symbolic link `test2' to `test/file': Operation not permitted trying to create symlinks. No problems creating symlinks with 2.4.33.3. Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problems with latest smbfs changes on 2.4.34 and security backports
On Thu, 18 Jan 2007 05:21:16 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:
>Hi Grant !
>
>On Thu, Jan 18, 2007 at 11:09:57AM +1100, Grant Coady wrote:
>(...)
>> >} else {
>> >- mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >- S_IROTH | S_IXOTH | S_IFREG;
>> >- mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >- S_IROTH | S_IXOTH | S_IFDIR;
>> >+ mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >+ S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
>> >+ mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >+ S_IROTH | S_IXOTH | S_IFDIR;
>> >if (parse_options(mnt, raw_data))
>> >goto out_bad_option;
>>
>> I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks
>> to directories seen as target, nor can they be created (Operation not
>> permitted...)
>
>Thanks very much Grant for the test. Could you try a symlink to a file ?
"Operation not permitted"
>And while we're at it, would you like to try to add "|S_IFLNK" to
>mnt->dir_mode ? If my suggestion was stupid, at least let's test it to
>full extent ;-)
Yep, already tried the obvious ;) no difference :(
2.4.33.5 onwards also have a problem with symlinks, but it is slightly
different presentation, the directory symlinks appear as normal files.
With 2.4.33.7 one is able to create file and directory symlinks, though
the links appear as files. Content problem as noted by OP:
[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.7
[EMAIL PROTECTED]:/home/other$ cat file
this is a test
[EMAIL PROTECTED]:/home/other$ cat filelink
[EMAIL PROTECTED]:/home/other$
[EMAIL PROTECTED]:/home/other$ mkdir directory
[EMAIL PROTECTED]:/home/other$ ln -s directory directorylink
[EMAIL PROTECTED]:/home/other$ cp file* directory
[EMAIL PROTECTED]:/home/other$ ls directory
file* filelink*
[EMAIL PROTECTED]:/home/other$ ls directorylink
directorylink*
Now, WinXP sees the contents of directorylink:
X:\>cd directorylink
X:\directorylink>dir
Volume in drive X is other
Volume Serial Number is 107E-052F
Directory of X:\directorylink
2007-01-18 16:36 .
2007-01-18 16:33 ..
2007-01-18 16:3615 file
2007-01-18 16:36 4 filelink
2 File(s) 19 bytes
2 Dir(s) 2,558,922,752 bytes free
X:\directorylink>type file
this is a test
X:\directorylink>type filelink
this
X:\directorylink>
>
>I had another idea looking at the code but since I really don't know it,
>I would not like to propose random changes till this magically works. I'd
>wait for Dann who understood the code.
Grant.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 6/6] bidi support: iSCSI bidi & varlen CDBs
This patch is intended to provide a working example of a use case
for bidi and varlen CDBs. The actual patches will be sent via the
open-iscsi project.
- Use proposed SCSI implementation for iSCSI bidirectional commands.
- Use proposed block layer implementation for iSCSI extended CDBs.
- Dynamically build AHSs for extended cdbs and bidirectional requests.
- Follow iscsi rfc-3720 concerning datasn and r2tsn with bidirectional commands,
these must be the same counter.
[- Remove check for first-burst bigger than max-burst so iSCSI regression tests
can pass.
this is the wrong fix and will be removed in actual patches]
Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/iser/iscsi_iser.c |4 +-
drivers/scsi/iscsi_tcp.c | 190 +++---
drivers/scsi/iscsi_tcp.h | 10 +-
drivers/scsi/libiscsi.c | 33 +++--
include/scsi/iscsi_proto.h |8 ++
include/scsi/libiscsi.h | 18 +++-
6 files changed, 200 insertions(+), 63 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index dd221ed..a0eae0c 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -140,10 +140,10 @@ iscsi_iser_cmd_init(struct iscsi_cmd_tas
iser_ctask->iser_conn= iser_conn;
if (sc->sc_data_direction == DMA_TO_DEVICE) {
- BUG_ON(ctask->total_length == 0);
+ BUG_ON(iscsi_out_total_length(ctask) == 0);
debug_scsi("cmd [itt %x total %d imm %d unsol_data %d\n",
- ctask->itt, ctask->total_length, ctask->imm_count,
+ ctask->itt, iscsi_out_total_length(ctask),
ctask->imm_count,
ctask->unsol_count);
}
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index d0b139c..2bc57a5 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -109,7 +109,9 @@ iscsi_hdr_digest(struct iscsi_conn *conn
struct iscsi_tcp_conn *tcp_conn = conn->dd_data;
crypto_hash_digest(_conn->tx_hash, >sg, buf->sg.length, crc);
- buf->sg.length = tcp_conn->hdr_size;
+ buf->sg.length += sizeof(__u32);
+ debug_tcp("iscsi_hdr_digest: %p crc 0x%02x%02x%02x%02x\n",
+ crc, crc[0], crc[1], crc[2], crc[3]);
}
static inline int
@@ -229,14 +231,21 @@ iscsi_data_rsp(struct iscsi_conn *conn,
if (tcp_conn->in.datalen == 0)
return 0;
- if (ctask->datasn != datasn)
+ if (tcp_ctask->exp_datasn != datasn) {
+ debug_tcp("%s: ctask->datasn(%d) != rhdr->datasn(%d)\n",
+ __FUNCTION__, tcp_ctask->exp_datasn, datasn);
return ISCSI_ERR_DATASN;
+ }
- ctask->datasn++;
+ tcp_ctask->exp_datasn++;
tcp_ctask->data_offset = be32_to_cpu(rhdr->offset);
- if (tcp_ctask->data_offset + tcp_conn->in.datalen > ctask->total_length)
+ if (tcp_ctask->data_offset + tcp_conn->in.datalen >
iscsi_in_total_length(ctask)) {
+ debug_tcp("%s: data_offset(%d) + data_len(%d) >
total_length_in(%d)\n",
+ __FUNCTION__, tcp_ctask->data_offset,
+ tcp_conn->in.datalen, iscsi_in_total_length(ctask));
return ISCSI_ERR_DATA_OFFSET;
+ }
if (rhdr->flags & ISCSI_FLAG_DATA_STATUS) {
struct scsi_cmnd *sc = ctask->sc;
@@ -246,7 +255,7 @@ iscsi_data_rsp(struct iscsi_conn *conn,
int res_count = be32_to_cpu(rhdr->residual_count);
if (res_count > 0 &&
- res_count <= sc->request_bufflen) {
+ res_count <= iscsi_in_total_length(ctask)) {
sc->resid = res_count;
sc->result = (DID_OK << 16) | rhdr->cmd_status;
} else
@@ -281,6 +290,7 @@ iscsi_solicit_data_init(struct iscsi_con
{
struct iscsi_data *hdr;
struct scsi_cmnd *sc = ctask->sc;
+ struct scsi_cmnd_buff scb;
hdr = >dtask.hdr;
memset(hdr, 0, sizeof(struct iscsi_data));
@@ -308,12 +318,13 @@ iscsi_solicit_data_init(struct iscsi_con
iscsi_buf_init_iov(>headbuf, (char*)hdr,
sizeof(struct iscsi_hdr));
- if (sc->use_sg) {
+ scsi_get_out_buff(sc, );
+ if (scb.use_sg) {
int i, sg_count = 0;
- struct scatterlist *sg = sc->request_buffer;
+ struct scatterlist *sg = scb.buffer;
r2t->sg = NULL;
- for (i = 0; i < sc->use_sg; i++, sg += 1) {
+ for (i = 0; i < scb.use_sg; i++, sg += 1) {
/* FIXME: prefetch ? */
if (sg_count + sg->length >
[RFC 5/6] bidi support: varlen + OSD support
- Add support for varlen CDBs or large vendor specific commands in
struct request.
- Add support for above at SCSI level API's and devices.
- Add the OSD device type.
Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
block/ll_rw_blk.c |2 ++
drivers/scsi/scsi.c | 11 ---
drivers/scsi/scsi_debug.c |6 +-
drivers/scsi/scsi_lib.c | 24 +---
drivers/scsi/scsi_scan.c |1 +
include/linux/blkdev.h|6 ++
include/scsi/scsi.h |2 ++
include/scsi/scsi_cmnd.h | 20 +++-
include/scsi/scsi_host.h |8 +++-
9 files changed, 67 insertions(+), 13 deletions(-)
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 1358b35..04bc43e 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -256,6 +256,8 @@ static void rq_init(request_queue_t *q,
rq->q = q;
rq->special = NULL;
rq->data = NULL;
+ rq->varlen_cdb_len = 0;
+ rq->varlen_cdb = NULL;
rq->sense = NULL;
rq->end_io = NULL;
rq->end_io_data = NULL;
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 24cffd9..f835496 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -485,6 +485,7 @@ int scsi_dispatch_cmd(struct scsi_cmnd *
unsigned long flags = 0;
unsigned long timeout;
int rtn = 0;
+ int cdb_size;
/* check if the device is still usable */
if (unlikely(cmd->device->sdev_state == SDEV_DEL)) {
@@ -566,9 +567,13 @@ int scsi_dispatch_cmd(struct scsi_cmnd *
* Before we queue this command, check if the command
* length exceeds what the host adapter can handle.
*/
- if (CDB_SIZE(cmd) > cmd->device->host->max_cmd_len) {
- SCSI_LOG_MLQUEUE(3,
- printk("queuecommand : command too long.\n"));
+ cdb_size = cmd->request->varlen_cdb ?
+ cmd->request->varlen_cdb_len : COMMAND_SIZE(cmd->cmnd[0]);
+ if (cdb_size > cmd->device->host->max_cmd_len) {
+ SCSI_LOG_MLQUEUE(0,
+ printk("queuecommand : command too long. "
+ "cdb_size(%d) host->max_cmd_len(%d)\n",
+ cdb_size, cmd->device->host->max_cmd_len));
cmd->result = (DID_ABORT << 16);
scsi_done(cmd);
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 30ee3d7..8520873 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -1993,8 +1993,12 @@ static int scsi_debug_slave_configure(st
if (SCSI_DEBUG_OPT_NOISE & scsi_debug_opts)
printk(KERN_INFO "scsi_debug: slave_configure <%u %u %u %u>\n",
sdp->host->host_no, sdp->channel, sdp->id, sdp->lun);
- if (sdp->host->max_cmd_len != SCSI_DEBUG_MAX_CMD_LEN)
+ if (sdp->host->max_cmd_len < SCSI_DEBUG_MAX_CMD_LEN) {
+ printk(KERN_INFO
+ "scsi_debug: max_cmd_len(%d) < SCSI_DEBUG_MAX_CMD_LEN\n",
+ sdp->host->max_cmd_len);
sdp->host->max_cmd_len = SCSI_DEBUG_MAX_CMD_LEN;
+ }
devip = devInfoReg(sdp);
sdp->hostdata = devip;
if (sdp->host->cmd_per_lun)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 92d3d44..d672ade 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -189,8 +189,17 @@ int scsi_execute(struct scsi_device *sde
buffer, bufflen, __GFP_WAIT))
goto out;
- req->cmd_len = COMMAND_SIZE(cmd[0]);
+ if (cmd[0] == VARLEN_CDB) {
+ req->varlen_cdb_len = scsi_varlen_cdb_length(cmd);
+ req->varlen_cdb = (unsigned char *)cmd; /* varlen cmd is
pointed to */
+ }
+ req->cmd_len = min(
+ req->varlen_cdb_len ? req->varlen_cdb_len :
COMMAND_SIZE(cmd[0]),
+ MAX_COMMAND_SIZE);
memcpy(req->cmd, cmd, req->cmd_len);
+ if (req->cmd_len < MAX_COMMAND_SIZE)
+ memset(>cmd[req->cmd_len], 0,
MAX_COMMAND_SIZE-req->cmd_len);
+
req->sense = sense;
req->sense_len = 0;
req->retries = retries;
@@ -452,8 +461,6 @@ int scsi_execute_bidi_async(struct scsi_
if (err)
goto free_req;
- req->cmd_len = cmd_len;
- memset(req->cmd, 0, BLK_MAX_CDB); /* ATAPI hates garbage after CDB */
if (is_bidi) {
if (bidi_read_buff->use_sg)
err = scsi_req_map_sg(
@@ -469,7 +476,18 @@ int scsi_execute_bidi_async(struct scsi_
}
}
+ BUG_ON( (cmd[0]==VARLEN_CDB) && (scsi_varlen_cdb_length(cmd) > cmd_len)
);
+ /* Unlike scsi_excute, scsi_execute_bidi_xxx supports big commands that
are not VARLEN_CDB */
+ if ((cmd[0] == VARLEN_CDB) || (cmd_len > MAX_COMMAND_SIZE)) {
+
[RFC 4/6] bidi support: bidirectional SCSI layer
- Add bidi members to struct scsi_cmnd.
- Add API at the SCSI level for bidirectional commands.
- Implement support for BIDI requests in scsi_setup_blk_pc_cmnd() and
scsi_io_completion().
Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_lib.c| 324 +++-
include/scsi/scsi_cmnd.h | 55 +++-
include/scsi/scsi_device.h | 16 ++
3 files changed, 330 insertions(+), 65 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 9c21025..92d3d44 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -246,27 +246,28 @@ static void scsi_end_async(struct reques
{
struct scsi_io_context *sioc = req->end_io_data;
- if (sioc->done)
- sioc->done(sioc->data, sioc->sense, req->errors,
rq_uni(req)->data_len);
+ if (sioc->done) /* FIXME: API of done needs to change for bidi
requests*/
+ sioc->done(sioc->data, sioc->sense, req->errors,
req->uni.data_len);
kmem_cache_free(scsi_io_context_cache, sioc);
__blk_put_request(req->q, req);
}
-static int scsi_merge_bio(struct request *rq, struct bio *bio)
+static int scsi_merge_bio(struct request *rq, struct bio *bio,
+ enum dma_data_direction dir)
{
struct request_queue *q = rq->q;
- struct request_io_part* req_io = rq_uni(rq);
+ struct request_io_part* req_io = rq_io(rq, dir);
bio->bi_flags &= ~(1 << BIO_SEG_VALID);
- if (rq_uni_write_dir(rq))
+ if (dir == DMA_TO_DEVICE)
bio->bi_rw |= (1 << BIO_RW);
else
bio->bi_rw &= ~(1 << BIO_RW);
blk_queue_bounce(q, );
- if (!rq_uni(rq)->bio)
- blk_rq_bio_prep(q, rq, bio);
+ if (!req_io->bio)
+ blk_rq_bio_prep_bidi(q, rq, bio, dir);
else if (!ll_back_merge_fn(q, rq, bio))
return -EINVAL;
else {
@@ -299,7 +300,7 @@ static int scsi_bi_endio(struct bio *bio
* sent to use, as some ULDs use that struct to only organize the pages.
*/
static int scsi_req_map_sg(struct request *rq, struct scatterlist *sgl,
- int nsegs, unsigned bufflen, gfp_t gfp)
+ int nsegs, unsigned bufflen, gfp_t gfp, enum dma_data_direction dir)
{
struct request_queue *q = rq->q;
int nr_pages = (bufflen + sgl[0].offset + PAGE_SIZE - 1) >> PAGE_SHIFT;
@@ -337,7 +338,7 @@ static int scsi_req_map_sg(struct reques
}
if (bio->bi_vcnt >= nr_vecs) {
- err = scsi_merge_bio(rq, bio);
+ err = scsi_merge_bio(rq, bio ,dir);
if (err) {
bio_endio(bio, bio->bi_size, 0);
goto free_bios;
@@ -352,12 +353,12 @@ static int scsi_req_map_sg(struct reques
}
rq->buffer = rq->data = NULL;
- rq_uni(rq)->data_len = data_len;
+ rq_io(rq,dir)->data_len = data_len;
return 0;
free_bios:
- while ((bio = rq_uni(rq)->bio) != NULL) {
- rq_uni(rq)->bio = bio->bi_next;
+ while ((bio = rq_io(rq,dir)->bio) != NULL) {
+ rq_io(rq,dir)->bio = bio->bi_next;
/*
* call endio instead of bio_put incase it was bounced
*/
@@ -385,31 +386,89 @@ int scsi_execute_async(struct scsi_devic
int use_sg, int timeout, int retries, void *privdata,
void (*done)(void *, char *, int, int), gfp_t gfp)
{
+ struct scsi_cmnd_buff buff;
+
+ buff.use_sg = use_sg;
+ buff.buffer = buffer;
+ buff.bufflen = bufflen;
+
+ return scsi_execute_bidi_async(
+ sdev, (unsigned char *)cmd, cmd_len, data_direction,
+ , NULL,
+ timeout, retries, privdata, done, gfp );
+}
+EXPORT_SYMBOL_GPL(scsi_execute_async);
+
+/**
+ * scsi_execute_bidi_async - insert bidi request, don't wait
+ * @sdev: scsi device
+ * @cmd: scsi command
+ * @cmd_len: length of scsi cdb
+ * @data_direction: data direction
+ * @bidi_write_buff.buffer:data buffer (this can be a kernel buffer or
scatterlist)
+ * @bidi_write_buff.bufflen: len of buffer
+ * @bidi_write_buff.use_sg:if buffer is a scatterlist this is the number
of elements
+ * @bidi_read_buff: same as above bidi_write_buff but for the bidi read part
+ * @timeout: request timeout in jiffies
+ * @retries: number of times to retry request
+ * @privdata: user data passed to done function
+ * @done: pointer to done function called at io completion.
+ * signature: void done(void *user_data, char *sence, int errors,
int data_bytes_advanced)
+ * @gfp: gfp allocation flags
+ **/
+int scsi_execute_bidi_async(struct scsi_device *sdev,
+ unsigned char
[RFC 3/6] bidi support: bidirectional request
- Instantiate another request_io_part in request for bidi_read.
- Define & Implement new API for accessing bidi parts.
- API to Build bidi requests and map to sglists.
- Define new end_that_request_block() function to end a complete request.
Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
block/elevator.c |7 +---
block/ll_rw_blk.c | 113 ++--
include/linux/blkdev.h | 49 -
3 files changed, 149 insertions(+), 20 deletions(-)
diff --git a/block/elevator.c b/block/elevator.c
index 0e9ea69..53b552e 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -741,14 +741,9 @@ struct request *elv_next_request(request
rq = NULL;
break;
} else if (ret == BLKPREP_KILL) {
- int nr_bytes = rq_uni(rq)->hard_nr_sectors << 9;
-
- if (!nr_bytes)
- nr_bytes = rq_uni(rq)->data_len;
-
blkdev_dequeue_request(rq);
rq->cmd_flags |= REQ_QUIET;
- end_that_request_chunk(rq, 0, nr_bytes);
+ end_that_request_block(rq, 0);
end_that_request_last(rq, 0);
} else {
printk(KERN_ERR "%s: bad return=%d\n", __FUNCTION__,
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 7d46f6a..1358b35 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -261,6 +261,7 @@ static void rq_init(request_queue_t *q,
rq->end_io_data = NULL;
rq->completion_data = NULL;
rq_init_io_part(>uni);
+ rq_init_io_part(>bidi_read);
}
/**
@@ -1312,15 +1313,16 @@ static int blk_hw_contig_segment(request
}
/*
- * map a request to scatterlist, return number of sg entries setup. Caller
- * must make sure sg can hold rq->nr_phys_segments entries
+ * map a request_io_part to scatterlist, return number of sg entries setup.
+ * Caller must make sure sg can hold rq_io(rq, dir)->nr_phys_segments entries
*/
-int blk_rq_map_sg(request_queue_t *q, struct request *rq, struct scatterlist
*sg)
+int blk_rq_map_sg_bidi(request_queue_t *q, struct request *rq,
+ struct scatterlist *sg, enum dma_data_direction dir)
{
struct bio_vec *bvec, *bvprv;
struct bio *bio;
int nsegs, i, cluster;
- struct request_io_part* req_io = rq_uni(rq);
+ struct request_io_part* req_io = rq_io(rq, dir);
nsegs = 0;
cluster = q->queue_flags & (1 << QUEUE_FLAG_CLUSTER);
@@ -1362,6 +1364,17 @@ new_segment:
return nsegs;
}
+EXPORT_SYMBOL(blk_rq_map_sg_bidi);
+
+/*
+ * map a request to scatterlist, return number of sg entries setup. Caller
+ * must make sure sg can hold rq->nr_phys_segments entries
+ */
+int blk_rq_map_sg(request_queue_t *q, struct request *rq, struct scatterlist
*sg)
+{
+ return blk_rq_map_sg_bidi(q, rq, sg, rq->data_dir);
+}
+
EXPORT_SYMBOL(blk_rq_map_sg);
/*
@@ -2561,15 +2574,18 @@ int blk_rq_unmap_user(struct bio *bio)
EXPORT_SYMBOL(blk_rq_unmap_user);
/**
- * blk_rq_map_kern - map kernel data to a request, for REQ_BLOCK_PC usage
+ * blk_rq_map_kern_bidi - maps kernel data to a request_io_part, for BIDI usage
* @q: request queue where request should be inserted
* @rq:request to fill
* @kbuf: the kernel buffer
* @len: length of user data
* @gfp_mask: memory allocation flags
+ * @dir:if it is a BIDIRECTIONAL request than DMA_TO_DEVICE to prepare
+ * the bidi_write side or DMA_FROM_DEVICE to prepare the bidi_read
+ * side, else it should be same as req->data_dir
*/
-int blk_rq_map_kern(request_queue_t *q, struct request *rq, void *kbuf,
- unsigned int len, gfp_t gfp_mask)
+int blk_rq_map_kern_bidi(request_queue_t *q, struct request *rq, void *kbuf,
+ unsigned int len, gfp_t gfp_mask, enum dma_data_direction dir)
{
struct bio *bio;
@@ -2582,14 +2598,30 @@ int blk_rq_map_kern(request_queue_t *q,
if (IS_ERR(bio))
return PTR_ERR(bio);
- if (rq_uni_write_dir(rq) == WRITE)
+ if (dma_write_dir(dir))
bio->bi_rw |= (1 << BIO_RW);
- blk_rq_bio_prep(q, rq, bio);
+ blk_rq_bio_prep_bidi(q, rq, bio ,dir);
rq->buffer = rq->data = NULL;
return 0;
}
+EXPORT_SYMBOL(blk_rq_map_kern_bidi);
+
+/**
+ * blk_rq_map_kern - map kernel data to a request, for REQ_BLOCK_PC usage
+ * @q: request queue where request should be inserted
+ * @rq:request to fill
+ * @kbuf: the kernel buffer
+ * @len: length of user data
+ * @gfp_mask: memory allocation flags
+ */
+int blk_rq_map_kern(request_queue_t *q, struct request *rq, void *kbuf,
+ unsigned int len, gfp_t gfp_mask)
+{
+ return blk_rq_map_kern_bidi( q, rq, kbuf, len, gfp_mask,
Re: [PATCH] Undo some of the pseudo-security madness
David Wagner wrote: > Samium Gromoff wrote: > >the core of the problem are the cores which are customarily > >dumped by lisps during the environment generation (or modification) stage, > >and then mapped back, every time the environment is invoked. > > > >at the current step of evolution, those core files are not relocatable > >in certain natively compiling lisp systems. > > > >in an even smaller subset of them, these cores are placed after > >the shared libraries and the executable. > > > >which obviously breaks when the latter are placed unpredictably. > >(yes, i know, currently mmap_base() varies over a 1MB range, but who > >says it will last indefinitely -- probably one day these people > >from full-disclosure will prevail and it will become, like, 256MB ;-) > > > >so, what do you propose? > > The obvious solution is: Don't make them setuid root. > Then this issue disappears. > > If there is some strong reason why they need to be setuid root, then > you'll need to explain that reason and your requirements in more detail. > But, based on your explanation so far, I have serious doubts about > whether it is a good idea to make such core-dumps setuid root in the > first place. not "core-dumps" but "core files", in the lispspeak, but anyway. the reason is trivial -- if i can write programs enjoying setuid privileges in C, i want to be able to do the same in Lisp. the only way to achieve this i see, is to directly setuid root the lisp system executable itself -- because the lisp code is read, compiled and executed in the process of the lisp system executable. there is such a thing as suid-perl -- for precise same reasons. regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB extension (repeater) cable
On Sun, 21 Jan 2007, Udo van den Heuvel wrote: H. Peter Anvin wrote: Greg KH wrote: On Fri, Jan 19, 2007 at 04:40:34PM +0100, Udo van den Heuvel wrote: I just tried my shiny new usb extension cable (repeater): Jan 19 16:01:17 epia kernel: usb 5-1: new high speed USB device using ehci_hcd and address 60 Jan 19 16:01:17 epia kernel: usb 5-1: configuration #1 chosen from 1 choice Jan 19 16:01:17 epia kernel: hub 5-1:1.0: USB hub found Jan 19 16:01:17 epia kernel: hub 5-1:1.0: 4 ports detected Jan 19 16:01:18 epia kernel: hub 5-1:1.0: Cannot enable port 1. Maybe the USB cable is bad? Jan 19 16:01:22 epia last message repeated 3 times Jan 19 16:01:23 epia kernel: hub 5-1:1.0: Cannot enable port 2. Maybe the USB cable is bad? Jan 19 16:01:26 epia last message repeated 3 times Jan 19 16:01:27 epia kernel: hub 5-1:1.0: Cannot enable port 3. Maybe the USB cable is bad? Jan 19 16:01:31 epia last message repeated 3 times [...] Actually, what it looks like is even simpler. The extension cable contains a four-port hub chip (which is the most common commodity chip) and haven't bothered changing the descriptor to tell the computer only one port is actually active. So only one port can be activated, and the others are stubbed out in some evil way. In that case, it should be noisy but harmless. I will do some more testing then. Is there a way to get rid of the messages? I am using the following patch (with 2.6.17) to shut up these messages with my repeater cable - found it on the linux-usb mailinglist some time ago when facing the same problem, but did not write down from who it is. (Does not silence all log messages when usb debugging is enabled, but when it is disabled there is no endless log-stream anymore and the cable works) I tried to fix the logging-change to the usb id, but the cable uses exactly the same chip and id as the two chips inside my 7port usb-hub. Index: linux/drivers/usb/core/hub.c === --- linux.orig/drivers/usb/core/hub.c 2006-10-14 00:45:50.0 +0200 +++ linux/drivers/usb/core/hub.c2006-10-14 00:47:38.0 +0200 @@ -1496,7 +1496,8 @@ /* bomb out completely if something weird happened */ if ((portchange & USB_PORT_STAT_C_CONNECTION)) - return -EINVAL; + //return -EINVAL; + return -ENOTCONN; /* if we`ve finished resetting, then break out of the loop */ if (!(portstatus & USB_PORT_STAT_RESET) && c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
David Wagner wrote: > Samium Gromoff wrote: > >the core of the problem are the cores which are customarily > >dumped by lisps during the environment generation (or modification) stage, > >and then mapped back, every time the environment is invoked. > > > >at the current step of evolution, those core files are not relocatable > >in certain natively compiling lisp systems. > > > >in an even smaller subset of them, these cores are placed after > >the shared libraries and the executable. > > > >which obviously breaks when the latter are placed unpredictably. > >(yes, i know, currently mmap_base() varies over a 1MB range, but who > >says it will last indefinitely -- probably one day these people > >from full-disclosure will prevail and it will become, like, 256MB ;-) > > > >so, what do you propose? > > The obvious solution is: Don't make them setuid root. > Then this issue disappears. > > If there is some strong reason why they need to be setuid root, then > you'll need to explain that reason and your requirements in more detail. > But, based on your explanation so far, I have serious doubts about > whether it is a good idea to make such core-dumps setuid root in the > first place. not "core-dumps" but "core files", in the lispspeak, but anyway. the reason is trivial -- if i can write programs enjoying setuid privileges in C, i want to be able to do the same in Lisp. the only way to achieve this i see, is to directly setuid root the lisp system executable itself -- because the lisp code is read, compiled and executed in the process of the lisp system executable. there is such a thing as suid-perl -- for precise same reasons. regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problems with latest smbfs changes on 2.4.34 and security backports
Hi Grant ! On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote: > On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote: > > >On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote: > >Ah, think I see the problem now: > > > >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c2007-01-19 > >17:53:57.247695476 -0700 > >+++ kernel-source-2.4.27/fs/smbfs/proc.c 2007-01-19 17:49:07.480161733 > >-0700 > >@@ -1997,7 +1997,7 @@ > > fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | > > S_IRWXO)) | S_IFDIR; > > else if ( (server->mnt->flags & SMB_MOUNT_FMODE) && > > !(S_ISDIR(fattr->f_mode)) ) > >-fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | > >S_IRWXO)) | S_IFREG; > >+fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | > >S_IRWXO)) | (fattr->f_mode & S_IFMT); > > > > } > > > client running 2.4.34 with above patch, server is running 2.6.19.2 to > eliminate it from the problem space (hopefully ;) : > [EMAIL PROTECTED]:/home/other$ uname -r > 2.4.34b > [EMAIL PROTECTED]:/home/other$ ls -l > total 9 > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/ > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/ > -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file* > -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 filelink* It seems to me that there is a difference, because filelink now appears the same size as file. It's just as if we had hard links instead of symlinks. > [EMAIL PROTECTED]:/home/other$ ls -l dirlink/ > total 1 > -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 file* > -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 filelink* > [EMAIL PROTECTED]:/home/other$ > > problem is still there :( At least, directories appear as hard links too. > With client 2.4.33.3 (slackware-11 distro kernel): > [EMAIL PROTECTED]:/home/other$ uname -r > 2.4.33.3 > [EMAIL PROTECTED]:/home/other$ ls -l > total 2048 > drwxr-xr-x 1 root root 0 2007-01-21 11:44 dir/ > lrwxrwxrwx 1 root root 3 2007-01-21 11:43 dirlink -> dir/ > -rw-r--r-- 1 root root 15 2007-01-21 11:43 file > lrwxrwxrwx 1 root root 4 2007-01-21 11:44 filelink -> file > [EMAIL PROTECTED]:/home/other$ ls -l dirlink/ > total 2048 > -rw-r--r-- 1 root root 15 2007-01-21 11:44 file > lrwxrwxrwx 1 root root 4 2007-01-21 11:44 filelink -> file > [EMAIL PROTECTED]:/home/other$ cat filelink > this is a test > > No problem with symlinks, execute flag. > > Grant. Thanks for your tests ! Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] CIFS: Remove 2 unneeded kzalloc casts
thx - I have added these to the cifs git tree.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
"Ahmed S. Darwish" <[EMAIL PROTECTED]> wrote on 01/06/2007 07:17:44 AM:
> Hi,
> A patch to remove two unnecessary kzalloc casts found
>
> Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
>
> diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
> index aedf683..90f95ed 100644
> --- a/fs/cifs/misc.c
> +++ b/fs/cifs/misc.c
> @@ -71,9 +71,7 @@ sesInfoAlloc(void)
> {
> struct cifsSesInfo *ret_buf;
>
> - ret_buf =
> - (struct cifsSesInfo *) kzalloc(sizeof (struct cifsSesInfo),
> - GFP_KERNEL);
> + ret_buf = kzalloc(sizeof (struct cifsSesInfo), GFP_KERNEL);
> if (ret_buf) {
>write_lock();
>atomic_inc();
> @@ -109,9 +107,8 @@ struct cifsTconInfo *
> tconInfoAlloc(void)
> {
> struct cifsTconInfo *ret_buf;
> - ret_buf =
> - (struct cifsTconInfo *) kzalloc(sizeof (struct cifsTconInfo),
> - GFP_KERNEL);
> + ret_buf = kzalloc(sizeof (struct cifsTconInfo),
> + GFP_KERNEL);
> if (ret_buf) {
>write_lock();
>atomic_inc();
>
> --
> Ahmed S. Darwish
> http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Johannes Schindelin wrote: > On Sun, 21 Jan 2007, Junio C Hamano wrote: >> * Reflog >> >> - Reflog records the history of where the tip of each branch >>was at each moment. > > It might make sense to reformulate that: > > Reflog records the history from the view point of the local > repository. In other words, regardless of the real history, > the reflog shows the history as seen by one particular repository > (this enables you to ask "what was the current revision in _this_ > repository, yesterday at 1pm?"). I think that _both_ sentences are right. Reflog records history of where the tip of each branch was at each moment, logging also what command was used to move tip of branch (was it commit, amending commit, rebase, reset, or creating branch anew, git-am or pull). But where tip of each branch was is purely local matter. What is global is DAG of commits, refs are always as seen by one particular repository. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Undo some of the pseudo-security madness
Samium Gromoff wrote: >the core of the problem are the cores which are customarily >dumped by lisps during the environment generation (or modification) stage, >and then mapped back, every time the environment is invoked. > >at the current step of evolution, those core files are not relocatable >in certain natively compiling lisp systems. > >in an even smaller subset of them, these cores are placed after >the shared libraries and the executable. > >which obviously breaks when the latter are placed unpredictably. >(yes, i know, currently mmap_base() varies over a 1MB range, but who >says it will last indefinitely -- probably one day these people >from full-disclosure will prevail and it will become, like, 256MB ;-) > >so, what do you propose? The obvious solution is: Don't make them setuid root. Then this issue disappears. If there is some strong reason why they need to be setuid root, then you'll need to explain that reason and your requirements in more detail. But, based on your explanation so far, I have serious doubts about whether it is a good idea to make such core-dumps setuid root in the first place. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
Björn Steinbrink wrote: On 2007.01.21 23:08:11 +0100, Björn Steinbrink wrote: On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: Björn Steinbrink wrote: All kernels were bad using that approach. So back to square 1. :/ Björn OK guys, here's a new patch to try against 2.6.20-rc5: Right now when switching between ADMA mode and legacy mode (i.e. when going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just set the ADMA GO register bit appropriately and continue with no delay. It looks like in some cases the controller doesn't respond to this immediately, it takes some nanoseconds for the controller's status registers to reflect the change that was made. It's possible that if we were trying to issue commands during this time, the controller might not react properly. This patch adds some code to wait for the status register to change to the state we asked for before continuing. I went for the "I feel lucky" route and did just add mmio reads after the mmio writes, posting them. Rationale being that if it is a write posting issue, the debug patch would/could actually hide it AFAICT. It's the "I feel lucky" route, because my whole "knowledge" about mmio and write posting originates from the few things I read up on when you discovered the comment about write posting in the generic ata code. Uhm, yeah, exception occured about the time that I hit "send". Björn Yeah, I don't think just adding reads to flush posted writes is enough here - it seems to need more delay than that, and it also wasn't always in the idle state even before we would write the register.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: > Björn Steinbrink wrote: > >All kernels were bad using that approach. So back to square 1. :/ > > > >Björn > > > > OK guys, here's a new patch to try against 2.6.20-rc5: > > Right now when switching between ADMA mode and legacy mode (i.e. when > going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just > set the ADMA GO register bit appropriately and continue with no delay. > It looks like in some cases the controller doesn't respond to this > immediately, it takes some nanoseconds for the controller's status > registers to reflect the change that was made. It's possible that if we > were trying to issue commands during this time, the controller might not > react properly. This patch adds some code to wait for the status > register to change to the state we asked for before continuing. Just got two exceptions with your patch, none of the debug messages were issued. Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Johannes Schindelin wrote: > On Sun, 21 Jan 2007, Jakub Narebski wrote: >> Johannes Schindelin wrote: >>> On Sun, 21 Jan 2007, Bill Lear wrote: >>> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? >>> >>> Direct your browser to >>> >>> http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f >> >> Better URL is >> >> http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2 > > It is a better URL. Somehow I fscked up when I tried it, so I had the > impression that does not work. But it does. Most probably you wrote '1.5.0-rc2' instead of 'v1.5.0-rc2' (with 'v' prefix). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
> > Talk about a cure worse than the disease! So you're > > saying that 256MB flash > > cards could be advertised as having 268.4MB? A 512MB RAM stick is > > mislabelled and could correctly say 536.8MB? That's just plain > > craziness. > No, I meant to advertise it as a 256 MiB flash device and a 512 MiB > flash device, as the Mi prefix has a single interpretation, that is 2 > to the power of 20, as per IEC 60027-2, whereas M has not if used > outside SI units. If it actually has 256*2^20 bytes, why advertise it as "256 MiB" when "268.4 MB" is equally valid and looks better? It really comes down to this: is it your position that "256 MB" can only correctly mean 256 million bytes? If you are right, a "512MB" RAM stick is mislabelled and is more correctly labelled as "536.8MB". (With 512MiB being equally correct.) Isn't that obviously not just wrong but borderline crazy? Yes, your position has some nice consequences, but that doesn't allow you to ignore the bad ones. Unfortunately, we're not writing on a clean slate here. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
On 2007.01.21 23:08:11 +0100, Björn Steinbrink wrote: > On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: > > Björn Steinbrink wrote: > > >All kernels were bad using that approach. So back to square 1. :/ > > > > > >Björn > > > > > > > OK guys, here's a new patch to try against 2.6.20-rc5: > > > > Right now when switching between ADMA mode and legacy mode (i.e. when > > going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just > > set the ADMA GO register bit appropriately and continue with no delay. > > It looks like in some cases the controller doesn't respond to this > > immediately, it takes some nanoseconds for the controller's status > > registers to reflect the change that was made. It's possible that if we > > were trying to issue commands during this time, the controller might not > > react properly. This patch adds some code to wait for the status > > register to change to the state we asked for before continuing. > > I went for the "I feel lucky" route and did just add mmio reads after the > mmio writes, posting them. Rationale being that if it is a write posting > issue, the debug patch would/could actually hide it AFAICT. > It's the "I feel lucky" route, because my whole "knowledge" about mmio > and write posting originates from the few things I read up on when you > discovered the comment about write posting in the generic ata code. Uhm, yeah, exception occured about the time that I hit "send". Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Undo some of the pseudo-security madness
At Sun, 21 Jan 2007 03:16:04 +0100, Arjan van de Ven wrote: > > On Sat, 2007-01-20 at 17:37 +0300, Samium Gromoff wrote: > > This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of > > setuid > > binaries. > > > > Why? The answer consists of two parts: > > > > Firstly, there are valid applications which need an unadulterated memory > > map. > > Some of those which do their memory management, like lisp systems (like > > SBCL). > > They try to achieve this by setting ADDR_NO_RANDOMIZE and reexecuting > > themselves. > > this is a ... funny way of achieving this > > if an application for some reason wants some fixed address for a piece > of memory there are other ways to do that (but to some degree all > apps that can't take randomization broken; for example a glibc upgrade > on a system will also move the address space around by virtue of being > bigger or smaller etc etc) the core of the problem are the cores which are customarily dumped by lisps during the environment generation (or modification) stage, and then mapped back, every time the environment is invoked. at the current step of evolution, those core files are not relocatable in certain natively compiling lisp systems. in an even smaller subset of them, these cores are placed after the shared libraries and the executable. which obviously breaks when the latter are placed unpredictably. (yes, i know, currently mmap_base() varies over a 1MB range, but who says it will last indefinitely -- probably one day these people from full-disclosure will prevail and it will become, like, 256MB ;-) so, what do you propose? regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: > Björn Steinbrink wrote: > >All kernels were bad using that approach. So back to square 1. :/ > > > >Björn > > > > OK guys, here's a new patch to try against 2.6.20-rc5: > > Right now when switching between ADMA mode and legacy mode (i.e. when > going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just > set the ADMA GO register bit appropriately and continue with no delay. > It looks like in some cases the controller doesn't respond to this > immediately, it takes some nanoseconds for the controller's status > registers to reflect the change that was made. It's possible that if we > were trying to issue commands during this time, the controller might not > react properly. This patch adds some code to wait for the status > register to change to the state we asked for before continuing. I went for the "I feel lucky" route and did just add mmio reads after the mmio writes, posting them. Rationale being that if it is a write posting issue, the debug patch would/could actually hide it AFAICT. It's the "I feel lucky" route, because my whole "knowledge" about mmio and write posting originates from the few things I read up on when you discovered the comment about write posting in the generic ata code. Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
Eduard Bloch wrote: > * Bodo Eggert [Sun, Jan 21 2007, 11:40:40AM]: >> 2) No sane person would say kibibyte as required by the standard. You'd need >>a sppech defect in order to do this, and a mental defect in order to try. >>So why should anybody adhere to the rest of this bullshit? > > You talk for everybody, or is it just your (and only your) mind refusing > to accept new terms? I'd say it is the refusal to accept new *dumb* terms. -- Stefan Richter -=-=-=== ---= =-=-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] e100: eth0 appers many times in /proc/interrupts after resume
On Sun, Jan 21, 2007 at 01:45:27PM -0800, Auke Kok wrote:
> Frederik Deweerdt wrote:
> >On Sun, Jan 21, 2007 at 09:17:41PM +0200, Andrei Popa wrote:
> >>It's the 10th resume and in /proc/interrupts eth0 appers 10 times.
> >The e100_resume() function should be calling netif_device_detach and
> >free_irq. Could you try the following (compile tested) patch?
>
> I just fixed suspend/shutdown for e100 in 2.6.19, not sure why the problem
> still shows up. Since it's a driver/net issue, you
> should CC netdev on it tho, otherwise it might go unnoticed.
Thanks for adding the CC
>
> I'll open up the can-o-worms on this issue and see what's up with it.
>
> I'm not so sure that this patch is OK, and I wonder why it stopped working,
> because I spent quite some time fixing it only a
> few months ago. Did swsup change again? sigh...
I may well be wrong (It appears that most of the time I am :)), but the
unbalanced netif_device_attach (in resume) looks suspicious. resume()
also calls request_irq, so calling free_irq on suspend seemed logical.
Regards,
Frederik
>
> Auke
>
> >Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
> >diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> >index 2fe0445..0c376e4 100644
> >--- a/drivers/net/e100.c
> >+++ b/drivers/net/e100.c
> >@@ -2671,6 +2671,7 @@ static int e100_suspend(struct pci_dev *pdev,
> >pm_message_t state)
> > del_timer_sync(>watchdog);
> > netif_carrier_off(nic->netdev);
> > + netif_device_detach(netdev);
> > pci_save_state(pdev);
> > if ((nic->flags & wol_magic) | e100_asf(nic)) {
> >@@ -2682,6 +2683,7 @@ static int e100_suspend(struct pci_dev *pdev,
> >pm_message_t state)
> > }
> > pci_disable_device(pdev);
> >+free_irq(pdev->irq, netdev);
> > pci_set_power_state(pdev, PCI_D3hot);
> > return 0;
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to [EMAIL PROTECTED]
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20 1/2] ehca: ehca_cq.c: fix unproper use of yield within spinlock context
Very minor but
> Signed-off-by Hoang-Nam Nguyen <[EMAIL PROTECTED]>
should be
Signed-off-by: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
(':' after the "-by")
Anyway, queued for 2.6.20, thanks.
- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Hi, On Sun, 21 Jan 2007, Jakub Narebski wrote: > Johannes Schindelin wrote: > > > On Sun, 21 Jan 2007, Bill Lear wrote: > > > >> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? > > > > Direct your browser to > > > > http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f > > Better URL is > > http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2 It is a better URL. Somehow I fscked up when I tried it, so I had the impression that does not work. But it does. Sorry, Dscho - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Hi, On Sun, 21 Jan 2007, Junio C Hamano wrote: > - 'git pack-refs' appeared in v1.4.4; You should probably mention that it is not necessary to run git-pack-refs by hand: git-gc is what you want. BTW have I praised y'all for inventing git-gc? It is _awesome_. I think I will turn into a DWIM geek yet; it is s much more convenient to issue "git gc" from time to time, than to think exactly about what I want to clean up right now. > - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were >seriously enhanced during v1.4.0 timeperiod. Should we introduce "git config" in time for the "let's please end-users" release (1.5.0)? > - git-clone always uses what is known as "separate remote" >layout for a newly created repository with a working tree; >i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are >used to track branches from the origin. ... instead of $GIT_DIR/refs/heads/, making the difference between remotely tracked and local branches more obvious. > - git-branch and git-show-branch know remote tracking branches. ... (use the command line switch "-r" to list only tracked branches.) > - git-push can now be used to delete a remote branch or a tag. >This requires the updated git on the remote side. ... (use "git push :refs/heads/" to delete "branch".) > - git-push more agressively keeps the transferred objects >packed. Earlier we recommended to monitor amount of loose >objects and repack regularly, but you should repack when you >accumulated too many small packs this way as well. Updated >git-count-objects helps you with this. It might make sense to enable something similar for git-fetch in time for 1.5.0. > * Reflog > > - Reflog records the history of where the tip of each branch >was at each moment. It might make sense to reformulate that: Reflog records the history from the view point of the local repository. In other words, regardless of the real history, the reflog shows the history as seen by one particular repository (this enables you to ask "what was the current revision in _this_ repository, yesterday at 1pm?"). > - There is a toplevel garbage collector script, 'git-gc', that >is an easy way to run 'git-repack -a -d', 'git-reflog gc', >and 'git-prune'. Did I mention that I really _love_ git-gc? > - The original implementation of git-merge-recursive which was >in Python has been removed; we have C implementation of it >now. I am no native speaker, but should that not be "we have a C implementation" instead? > - The default suffix for git-format-patch output is now ".patch", >not ".txt". This can be changed with --suffix=.txt option, >or "format.suffix = .txt" in the configuration. I fully expect people to complain that a config like this format.suffix = .txt does not work. better say ... or setting the config variable "format.suffix" to ".txt". > - Better error messages for often used Porcelainish commands. Amen. I think this really helped a lot of people already. >- Cloning and fetching _from_ a shallow clone are not > supported (nor tested -- so they might work by accident but > they are not expected to). Maybe we should go the "restrict first, and loosen later" approach? I.e. forbid git-upload-pack to run if is_repository_shallow()? >- Pushing from nor into a shallow clone are not expected to > work. Maybe forbid git-push and git-receive-pack to run if is_repository_shallow()? (I _think_ git-push should be safe, but not git-receive-pack.) Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] e100: eth0 appers many times in /proc/interrupts after resume
Frederik Deweerdt wrote:
On Sun, Jan 21, 2007 at 09:17:41PM +0200, Andrei Popa wrote:
It's the 10th resume and in /proc/interrupts eth0 appers 10 times.
The e100_resume() function should be calling netif_device_detach and
free_irq. Could you try the following (compile tested) patch?
I just fixed suspend/shutdown for e100 in 2.6.19, not sure why the problem still
shows up. Since it's a driver/net issue, you should CC netdev on it tho,
otherwise it might go unnoticed.
I'll open up the can-o-worms on this issue and see what's up with it.
I'm not so sure that this patch is OK, and I wonder why it stopped working,
because I spent quite some time fixing it only a few months ago. Did swsup
change again? sigh...
Auke
Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 2fe0445..0c376e4 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2671,6 +2671,7 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
del_timer_sync(>watchdog);
netif_carrier_off(nic->netdev);
+ netif_device_detach(netdev);
pci_save_state(pdev);
if ((nic->flags & wol_magic) | e100_asf(nic)) {
@@ -2682,6 +2683,7 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
}
pci_disable_device(pdev);
+ free_irq(pdev->irq, netdev);
pci_set_power_state(pdev, PCI_D3hot);
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/irda/vlsi_ir.{h,c}: remove kernel 2.4 code
On Thu, Jan 18, 2007 at 10:56:13PM +0100, Adrian Bunk wrote:
> This patch removes kernel 2.4 compatibility code.
Looks correct to me, thanks.
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Samuel Ortiz <[EMAIL PROTECTED]>
> ---
>
> drivers/net/irda/vlsi_ir.c | 16
> drivers/net/irda/vlsi_ir.h | 33 -
> 2 files changed, 8 insertions(+), 41 deletions(-)
>
> --- linux-2.6.20-rc4-mm1/drivers/net/irda/vlsi_ir.h.old 2007-01-18
> 21:50:43.0 +0100
> +++ linux-2.6.20-rc4-mm1/drivers/net/irda/vlsi_ir.h 2007-01-18
> 21:53:54.0 +0100
> @@ -41,39 +41,6 @@
> #define PCI_CLASS_SUBCLASS_MASK 0x
> #endif
>
> -/* in recent 2.5 interrupt handlers have non-void return value */
> -#ifndef IRQ_RETVAL
> -typedef void irqreturn_t;
> -#define IRQ_NONE
> -#define IRQ_HANDLED
> -#define IRQ_RETVAL(x)
> -#endif
> -
> -/* some stuff need to check kernelversion. Not all 2.5 stuff was present
> - * in early 2.5.x - the test is merely to separate 2.4 from 2.5
> - */
> -#include
> -
> -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
> -
> -/* PDE() introduced in 2.5.4 */
> -#ifdef CONFIG_PROC_FS
> -#define PDE(inode) ((inode)->i_private)
> -#endif
> -
> -/* irda crc16 calculation exported in 2.5.42 */
> -#define irda_calc_crc16(fcs,buf,len) (GOOD_FCS)
> -
> -/* we use this for unified pci device name access */
> -#define PCIDEV_NAME(pdev)((pdev)->name)
> -
> -#else /* 2.5 or later */
> -
> -/* whatever we get from the associated struct device - bus:slot:dev.fn id */
> -#define PCIDEV_NAME(pdev)(pci_name(pdev))
> -
> -#endif
> -
> /* */
>
> /* non-standard PCI registers */
> --- linux-2.6.20-rc4-mm1/drivers/net/irda/vlsi_ir.c.old 2007-01-18
> 21:53:58.0 +0100
> +++ linux-2.6.20-rc4-mm1/drivers/net/irda/vlsi_ir.c 2007-01-18
> 21:54:56.0 +0100
> @@ -166,7 +166,7 @@
> unsigned i;
>
> seq_printf(seq, "\n%s (vid/did: %04x/%04x)\n",
> -PCIDEV_NAME(pdev), (int)pdev->vendor, (int)pdev->device);
> +pci_name(pdev), (int)pdev->vendor, (int)pdev->device);
> seq_printf(seq, "pci-power-state: %u\n", (unsigned)
> pdev->current_state);
> seq_printf(seq, "resources: irq=%u / io=0x%04x / dma_mask=0x%016Lx\n",
> pdev->irq, (unsigned)pci_resource_start(pdev, 0), (unsigned
> long long)pdev->dma_mask);
> @@ -1401,7 +1401,7 @@
>
> if (vlsi_start_hw(idev))
> IRDA_ERROR("%s: failed to restart hw - %s(%s) unusable!\n",
> -__FUNCTION__, PCIDEV_NAME(idev->pdev), ndev->name);
> +__FUNCTION__, pci_name(idev->pdev), ndev->name);
> else
> netif_start_queue(ndev);
> }
> @@ -1643,7 +1643,7 @@
> pdev->current_state = 0; /* hw must be running now */
>
> IRDA_MESSAGE("%s: IrDA PCI controller %s detected\n",
> - drivername, PCIDEV_NAME(pdev));
> + drivername, pci_name(pdev));
>
> if ( !pci_resource_start(pdev,0)
>|| !(pci_resource_flags(pdev,0) & IORESOURCE_IO) ) {
> @@ -1728,7 +1728,7 @@
>
> pci_set_drvdata(pdev, NULL);
>
> - IRDA_MESSAGE("%s: %s removed\n", drivername, PCIDEV_NAME(pdev));
> + IRDA_MESSAGE("%s: %s removed\n", drivername, pci_name(pdev));
> }
>
> #ifdef CONFIG_PM
> @@ -1748,7 +1748,7 @@
>
> if (!ndev) {
> IRDA_ERROR("%s - %s: no netdevice \n",
> -__FUNCTION__, PCIDEV_NAME(pdev));
> +__FUNCTION__, pci_name(pdev));
> return 0;
> }
> idev = ndev->priv;
> @@ -1759,7 +1759,7 @@
> pdev->current_state = state.event;
> }
> else
> - IRDA_ERROR("%s - %s: invalid suspend request %u ->
> %u\n", __FUNCTION__, PCIDEV_NAME(pdev), pdev->current_state, state.event);
> + IRDA_ERROR("%s - %s: invalid suspend request %u ->
> %u\n", __FUNCTION__, pci_name(pdev), pdev->current_state, state.event);
> up(>sem);
> return 0;
> }
> @@ -1787,7 +1787,7 @@
>
> if (!ndev) {
> IRDA_ERROR("%s - %s: no netdevice \n",
> -__FUNCTION__, PCIDEV_NAME(pdev));
> +__FUNCTION__, pci_name(pdev));
> return 0;
> }
> idev = ndev->priv;
> @@ -1795,7 +1795,7 @@
> if (pdev->current_state == 0) {
> up(>sem);
> IRDA_WARNING("%s - %s: already resumed\n",
> - __FUNCTION__, PCIDEV_NAME(pdev));
> + __FUNCTION__, pci_name(pdev));
> return 0;
> }
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH] Undo some of the pseudo-security madness
At Sun, 21 Jan 2007 03:16:04 +0100, Arjan van de Ven wrote: > On Sat, 2007-01-20 at 17:37 +0300, Samium Gromoff wrote: > > This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of > > setuid > > binaries. > > > > Why? The answer consists of two parts: > > > > Firstly, there are valid applications which need an unadulterated memory > > map. > > Some of those which do their memory management, like lisp systems (like > > SBCL). > > They try to achieve this by setting ADDR_NO_RANDOMIZE and reexecuting > > themselves. > > this is a ... funny way of achieving this > > if an application for some reason wants some fixed address for a piece > of memory there are other ways to do that (but to some degree all > apps that can't take randomization broken; for example a glibc upgrade > on a system will also move the address space around by virtue of being > bigger or smaller etc etc) > > [1]. See the excellent, 'Hackers Hut' by Andries Brouwer, which describes > > how AS randomisation can be got around by the means of linux-gate.so.1 > > got a URL to this? If this is exploiting the fact that the vdso is at a > fixed spot... it's no longer the case since quite a while. hmm, it seems to rely on that, yes: http://www.win.tue.nl/~aeb/linux/hhh/hh-9.html#ss9.6 > -- > if you want to mail me at work (you don't), use arjan (at) linux.intel.com > Test the interaction between Linux and your BIOS via > http://www.linuxfirmwarekit.org regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Johannes Schindelin wrote: > On Sun, 21 Jan 2007, Bill Lear wrote: > >> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? > > Direct your browser to > > http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f Better URL is http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2 -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird XFS slowness
On Jan 21 2007 02:29, S.Çağlar Onur wrote: >After switching ext3 to xfs, i realize system starts to _really_ >unresponsive and extracting tarballs, Please have a look at http://lkml.org/lkml/2006/5/22/278 -`J' --
Re: Running Linux on FPGA
On Jan 21 2007 00:14, Ralf Baechle wrote: >On Sat, Jan 20, 2007 at 11:42:37PM +, sathesh babu wrote: > >> I am trying to run Linux-2.6.18.2 ( with preemption enable) >> kernel on FPGA board which has MIPS24KE processor runs at 12 >> MHZ. Programmed the timer to give interrupt at every 10msec. I >> am seeing some inconsistence behavior during boot up processor. >> Some times it stops after "NET: Registered protocol family 17" >> and "VFS: Mounted root (jffs2 filesystem).". Could some give >> some pointers why the behavior is random. Is it OK to program >> the timer to 10 msec? or should it be more. > >The overhead of timer interrupts at this low clockrate is >significant so I recommend to minimize the timer interrupt rate as >far as possible. This is really a tradeoff between latency and >overhead and matters much less on hardcores which run at hundreds of >MHz. Hm I've been running 2.6.13 on a 10/20 MHz (switchable) i386 @ 100 Hz before without any hangs during boot or operation. -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
On Jan 21 2007 17:06, Heikki Orsila wrote: > >> 2) No sane person would say kibibyte as required by the standard. You'd need >>a sppech defect in order to do this, and a mental defect in order to try. >>So why should anybody adhere to the rest of this bullshit? > >I think I'm not sane then. I find it easy to use and pronounce. > >IEC 60027-2 is a great standard! It removes some annoying ambiquity in >speech and text. Adhering strictly to proper SI units (k, M, G, ...) >makes life easier as they are taught in school to everyone. Bleh. Except for storage, base 1024 was used for almost everything I remember. 4 MB memory meant 4096 KB, and that's still the case today. Most likely the same for transfer rates. It's just that storage vendors broke the computer rule and went with 1000. Just teach all the exceptions. No life is without. -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Hi, On Sun, 21 Jan 2007, Bill Lear wrote: > Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? Direct your browser to http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f BTW please don't top post. It uses bandwidth unnecessarily (both in terms of megabytes and attention). Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] eth0 appers many times in /proc/interrupts after resume
On Sun, Jan 21, 2007 at 09:17:41PM +0200, Andrei Popa wrote:
> It's the 10th resume and in /proc/interrupts eth0 appers 10 times.
>
Hi,
The e100_resume() function should be calling netif_device_detach and
free_irq. Could you try the following (compile tested) patch?
Regards,
Frederik
Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 2fe0445..0c376e4 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2671,6 +2671,7 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
del_timer_sync(>watchdog);
netif_carrier_off(nic->netdev);
+ netif_device_detach(netdev);
pci_save_state(pdev);
if ((nic->flags & wol_magic) | e100_asf(nic)) {
@@ -2682,6 +2683,7 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
}
pci_disable_device(pdev);
+ free_irq(pdev->irq, netdev);
pci_set_power_state(pdev, PCI_D3hot);
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
status of: tasklet_unlock_wait() causes soft lockup with -rt and ieee1394 audio
Dear all,
What is the status with respect to this problem? I see that in the
current -rt patch the problematic code piece is different. I personally
haven't tried to reproduce this myself on a more recent kernel, but I
just got a report from one of our users who experienced the same problem
with 2.6.19-rt15 and RT preemption (desktop preemption works fine).
Should the latest -rt patches be fixed with respect to this issue? If so
I'll try and test them, otherwise I omit the effort.
Thanks,
Pieter
Lee Revell wrote:
Pieter has found this bug in -rt:
We are experiencing 'soft' deadlocks when running our code (Freebob,
i.e. userspace lib for firewire audio) on RT kernels. After a few
seconds of system freeze, I get a kernel panic message that signals a soft lockup.
I've uploaded the photo's of the panic here:
http://freebob.sourceforge.net/old/img_3378.jpg (without flash)
http://freebob.sourceforge.net/old/img_3377.jpg (with flash)
both are of suboptimal quality unfortunately, but all info is readable
on one or the other.
The problems occur when an ISO stream (receive and/or transmit) is shut
down in a SCHED_FIFO thread. More precisely when running the freebob
jackd backend in real-time mode. And even more precise: they only seem
to occur when jackd is shut down. There are no problems when jackd is
started without RT scheduling.
I havent been able to reproduce this with other test programs that are
shutting down streams in a SCHED_FIFO thread.
The problem is not reproducible on non-RT kernels, and it only occurs on those configured for
PREEMPT_RT. If I use PREEMPT_DESKTOP, there is no problem. The PREEMPT_DESKTOP setting was the only change between the two tests, all other kernel settings (threaded irq's etc...) were unchanged.
My tests are performed on 2.6.17-rt1, but the lockups are confirmed for
PREEMPT_RT configured kernels 2.6.14 and 2.6.16.
Some extra information:
Lee Revell wrote:
<...>
It seems that the -rt patch changes tasklet_kill:
Unpatched 2.6.17:
void tasklet_kill(struct tasklet_struct *t)
{
if (in_interrupt())
printk("Attempt to kill tasklet from interrupt\n");
while (test_and_set_bit(TASKLET_STATE_SCHED, >state)) {
do
yield();
while (test_bit(TASKLET_STATE_SCHED, >state));
}
tasklet_unlock_wait(t);
clear_bit(TASKLET_STATE_SCHED, >state);
}
2.6.17-rt:
void tasklet_kill(struct tasklet_struct *t)
{
if (in_interrupt())
printk("Attempt to kill tasklet from interrupt\n");
while (test_and_set_bit(TASKLET_STATE_SCHED, >state)) {
do msleep(1);
while (test_bit(TASKLET_STATE_SCHED, >state));
}
tasklet_unlock_wait(t);
clear_bit(TASKLET_STATE_SCHED, >state);
}
You should ask Ingo & the other -rt developers what the intent of this
change was. Obviously it loops forever waiting for the state bit to
change.
On Thu, 2006-07-06 at 22:14 +0200, Pieter Palmers wrote:
I've put the debugging printk's into tasklet_kill. One interesting
remark is that now that they are in place, I had to start/stop jackd
multiple times before deadlock occurs. Without the printk's the machine
always locked up on the first pass. However I stopped after the first
lockup, so maybe this is not really significant.
Anyway, the new tasklet_kill looks like this:
void tasklet_kill(struct tasklet_struct *t)
{
printk("enter tasklet_kill\n");
if (in_interrupt())
printk("Attempt to kill tasklet from interrupt\n");
printk("passed interrupt check\n");
while (test_and_set_bit(TASKLET_STATE_SCHED, >state)) {
do
msleep(1);
while (test_bit(TASKLET_STATE_SCHED, >state));
}
printk("passed test_and_set_bit\n");
tasklet_unlock_wait(t);
printk("passed tasklet_unlock_wait\n");
clear_bit(TASKLET_STATE_SCHED, >state);
}
And the last line printed before lockup is:
"passed test_and_set_bit"
This makes the change in tasklet_unlock_wait() as the prime suspect for this
problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
>How fast is your Ethernet port? 100Mbps or 95.37Mbps? Same lie like with harddrives. It's around 80, not 100. But it depends on how you look at it. 80 for Layer3, possibly a little more for Layer2/1. -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
From: Jay Cliburn <[EMAIL PROTECTED]>
From: Chris Snook <[EMAIL PROTECTED]>
This patch contains auxiliary C files for the Attansic L1 gigabit ethernet
adapter driver.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
---
atl1_ethtool.c | 436 ++
atl1_hw.c | 728 +
atl1_param.c | 223 +
3 files changed, 1387 insertions(+)
diff --git a/drivers/net/atl1/atl1_ethtool.c b/drivers/net/atl1/atl1_ethtool.c
new file mode 100644
index 000..4c6e505
--- /dev/null
+++ b/drivers/net/atl1/atl1_ethtool.c
@@ -0,0 +1,436 @@
+/**
+ * Copyright(c) 2005 - 2006 Attansic Corporation. All rights reserved.
+ * Copyright(c) 2006 Chris Snook <[EMAIL PROTECTED]>
+ * Copyright(c) 2006 Jay Cliburn <[EMAIL PROTECTED]>
+ *
+ * Derived from Intel e1000 driver
+ * Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59
+ * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ **/
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "atl1.h"
+
+
+extern char atl1_driver_name[];
+extern char atl1_driver_version[];
+
+struct atl1_stats {
+ char stat_string[ETH_GSTRING_LEN];
+ int sizeof_stat;
+ int stat_offset;
+};
+
+#define ATL1_STAT(m) sizeof(((struct atl1_adapter *)0)->m), \
+ offsetof(struct atl1_adapter, m)
+
+static struct atl1_stats atl1_gstrings_stats[] = {
+ {"rx_packets", ATL1_STAT(soft_stats.rx_packets)},
+ {"tx_packets", ATL1_STAT(soft_stats.tx_packets)},
+ {"rx_bytes", ATL1_STAT(soft_stats.rx_bytes)},
+ {"tx_bytes", ATL1_STAT(soft_stats.tx_bytes)},
+ {"rx_errors", ATL1_STAT(soft_stats.rx_errors)},
+ {"tx_errors", ATL1_STAT(soft_stats.tx_errors)},
+ {"rx_dropped", ATL1_STAT(net_stats.rx_dropped)},
+ {"tx_dropped", ATL1_STAT(net_stats.tx_dropped)},
+ {"multicast", ATL1_STAT(soft_stats.multicast)},
+ {"collisions", ATL1_STAT(soft_stats.collisions)},
+ {"rx_length_errors", ATL1_STAT(soft_stats.rx_length_errors)},
+ {"rx_over_errors", ATL1_STAT(soft_stats.rx_missed_errors)},
+ {"rx_crc_errors", ATL1_STAT(soft_stats.rx_crc_errors)},
+ {"rx_frame_errors", ATL1_STAT(soft_stats.rx_frame_errors)},
+ {"rx_fifo_errors", ATL1_STAT(soft_stats.rx_fifo_errors)},
+ {"rx_missed_errors", ATL1_STAT(soft_stats.rx_missed_errors)},
+ {"tx_aborted_errors", ATL1_STAT(soft_stats.tx_aborted_errors)},
+ {"tx_carrier_errors", ATL1_STAT(soft_stats.tx_carrier_errors)},
+ {"tx_fifo_errors", ATL1_STAT(soft_stats.tx_fifo_errors)},
+ {"tx_window_errors", ATL1_STAT(soft_stats.tx_window_errors)},
+ {"tx_abort_exce_coll", ATL1_STAT(soft_stats.excecol)},
+ {"tx_abort_late_coll", ATL1_STAT(soft_stats.latecol)},
+ {"tx_deferred_ok", ATL1_STAT(soft_stats.deffer)},
+ {"tx_single_coll_ok", ATL1_STAT(soft_stats.scc)},
+ {"tx_multi_coll_ok", ATL1_STAT(soft_stats.mcc)},
+ {"tx_underun", ATL1_STAT(soft_stats.tx_underun)},
+ {"tx_trunc", ATL1_STAT(soft_stats.tx_trunc)},
+ {"tx_pause", ATL1_STAT(soft_stats.tx_pause)},
+ {"rx_pause", ATL1_STAT(soft_stats.rx_pause)},
+ {"rx_rrd_ov", ATL1_STAT(soft_stats.rx_rrd_ov)},
+ {"rx_trunc", ATL1_STAT(soft_stats.rx_trunc)}
+};
+
+static void atl1_get_ethtool_stats(struct net_device *netdev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct atl1_adapter *adapter = netdev_priv(netdev);
+ int i;
+ char *p;
+
+ for (i = 0; i < ARRAY_SIZE(atl1_gstrings_stats); i++) {
+ p = (char *)adapter+atl1_gstrings_stats[i].stat_offset;
+ data[i] = (atl1_gstrings_stats[i].sizeof_stat ==
+ sizeof(u64)) ? *(u64 *)p : *(u32 *)p;
+ }
+
+}
+
+static int atl1_get_stats_count(struct net_device *netdev)
+{
+ return ARRAY_SIZE(atl1_gstrings_stats);
+}
+
+static int atl1_get_settings(struct net_device *netdev, struct ethtool_cmd
*ecmd)
+{
+ struct atl1_adapter *adapter = netdev_priv(netdev);
+ struct atl1_hw *hw = >hw;
+
+ ecmd->supported = (SUPPORTED_10baseT_Half |
+ SUPPORTED_10baseT_Full |
+
[PATCH 2/4] atl1: Header files for Attansic L1 driver
From: Jay Cliburn <[EMAIL PROTECTED]>
From: Chris Snook <[EMAIL PROTECTED]>
This patch contains the header files needed by the Attansic L1 gigabit
ethernet adapter driver.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
---
atl1.h| 288 ++
atl1_hw.h | 965 ++
2 files changed, 1253 insertions(+)
diff --git a/drivers/net/atl1/atl1.h b/drivers/net/atl1/atl1.h
new file mode 100644
index 000..1d13e8f
--- /dev/null
+++ b/drivers/net/atl1/atl1.h
@@ -0,0 +1,288 @@
+/**
+ * Copyright(c) 2005 - 2006 Attansic Corporation. All rights reserved.
+ * Copyright(c) 2006 Chris Snook <[EMAIL PROTECTED]>
+ * Copyright(c) 2006 Jay Cliburn <[EMAIL PROTECTED]>
+ *
+ * Derived from Intel e1000 driver
+ * Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59
+ * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ **/
+
+#ifndef _ATL1_H_
+#define _ATL1_H_
+
+#include
+#include
+#include
+
+#include "atl1_hw.h"
+
+/* function prototypes needed by multiple files */
+s32 atl1_up(struct atl1_adapter *adapter);
+void atl1_down(struct atl1_adapter *adapter);
+int atl1_reset(struct atl1_adapter *adapter);
+s32 atl1_setup_ring_resources(struct atl1_adapter *adapter);
+void atl1_free_ring_resources(struct atl1_adapter *adapter);
+
+struct atl1_adapter;
+
+#define ATL1_MAX_INTR 3
+
+#define ATL1_DEFAULT_TPD 256
+#define ATL1_MAX_TPD 1023
+#define ATL1_MIN_TPD 64
+#define ATL1_DEFAULT_RFD 512
+#define ATL1_MIN_RFD 128
+#define ATL1_MAX_RFD 2047
+
+#define ATL1_GET_DESC(R, i, type) (&(((type *)((R)->desc))[i]))
+#define ATL1_RFD_DESC(R, i)ATL1_GET_DESC(R, i, struct rx_free_desc)
+#define ATL1_TPD_DESC(R, i)ATL1_GET_DESC(R, i, struct tx_packet_desc)
+#define ATL1_RRD_DESC(R, i)ATL1_GET_DESC(R, i, struct rx_return_desc)
+
+/**
+ * Some workarounds require millisecond delays and are run during interrupt
+ * context. Most notably, when establishing link, the phy may need tweaking
+ * but cannot process phy register reads/writes faster than millisecond
+ * intervals...and we establish link due to a "link status change" interrupt.
+ **/
+
+/**
+ * wrapper around a pointer to a socket buffer,
+ * so a DMA handle can be stored along with the buffer
+ **/
+struct atl1_buffer {
+ struct sk_buff *skb;
+ u16 length;
+ u16 alloced;
+ dma_addr_t dma;
+};
+
+#define MAX_TX_BUF_LEN 0x3000 /* 12KB */
+
+struct atl1_tpd_ring {
+ void *desc; /* pointer to the descriptor ring memory */
+ dma_addr_t dma; /* physical adress of the descriptor ring */
+ u16 size; /* length of descriptor ring in bytes */
+ u16 count; /* number of descriptors in the ring */
+
+ u16 hw_idx; /* hardware index */
+ atomic_t next_to_clean;
+ atomic_t next_to_use;
+ struct atl1_buffer *buffer_info;
+};
+
+struct atl1_rfd_ring {
+ void *desc;
+ dma_addr_t dma;
+ u16 size;
+ u16 count;
+ atomic_t next_to_use;
+ u16 next_to_clean;
+ struct atl1_buffer *buffer_info;
+};
+
+struct atl1_rrd_ring {
+ void *desc;
+ dma_addr_t dma;
+ unsigned int size;
+ u16 count;
+ u16 next_to_use;
+ atomic_t next_to_clean;
+};
+
+struct atl1_ring_header {
+ /* pointer to the descriptor ring memory */
+ void *desc;
+ /* physical adress of the descriptor ring */
+ dma_addr_t dma;
+ /* length of descriptor ring in bytes */
+ unsigned int size;
+};
+
+struct atl1_cmb {
+ struct coals_msg_block *cmb;
+ dma_addr_t dma;
+};
+
+struct atl1_smb {
+ struct stats_msg_block *smb;
+ dma_addr_t dma;
+};
+
+/* Statistics counters */
+struct atl1_sft_stats {
+ u64 rx_packets;
+ u64 tx_packets;
+ u64 rx_bytes;
+ u64 tx_bytes;
+ u64 multicast;
+ u64 collisions;
+ u64 rx_errors;
+ u64 rx_length_errors;
+ u64 rx_crc_errors;
+ u64 rx_frame_errors;
+ u64 rx_fifo_errors;
+ u64 rx_missed_errors;
+ u64 tx_errors;
+ u64 tx_fifo_errors;
+ u64 tx_aborted_errors;
+ u64
[PATCH 1/4] atl1: Build files for Attansic L1 driver
From: Jay Cliburn <[EMAIL PROTECTED]> From: Chris Snook <[EMAIL PROTECTED]> This patch contains the build files for the Attansic L1 gigabit ethernet adapter driver. Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]> Signed-off-by: Chris Snook <[EMAIL PROTECTED]> --- Kconfig | 11 +++ Makefile |1 + atl1/Makefile |2 ++ 3 files changed, 14 insertions(+) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 8aa8dd0..0bb3c1e 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2348,6 +2348,17 @@ config QLA3XXX To compile this driver as a module, choose M here: the module will be called qla3xxx. +config ATL1 + tristate "Attansic L1 Gigabit Ethernet support (EXPERIMENTAL)" + depends on NET_PCI && PCI && EXPERIMENTAL + select CRC32 + select MII + help + This driver supports the Attansic L1 gigabit ethernet adapter. + + To compile this driver as a module, choose M here. The module + will be called atl1. + endmenu # diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 4c0d4e5..d0beced 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_IXGB) += ixgb/ obj-$(CONFIG_CHELSIO_T1) += chelsio/ obj-$(CONFIG_EHEA) += ehea/ obj-$(CONFIG_BONDING) += bonding/ +obj-$(CONFIG_ATL1) += atl1/ obj-$(CONFIG_GIANFAR) += gianfar_driver.o gianfar_driver-objs := gianfar.o \ diff --git a/drivers/net/atl1/Makefile b/drivers/net/atl1/Makefile new file mode 100644 index 000..a6b707e --- /dev/null +++ b/drivers/net/atl1/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_ATL1) += atl1.o +atl1-y += atl1_main.o atl1_hw.o atl1_ethtool.o atl1_param.o - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On Jan 19 2007 10:11, Pavel Machek wrote: > >> this is a new 2.6.20 module implementing a user inactivity trigger. Basically >> it acts as an event sniffer, issuing an ACPI event when no user activity is >> detected for more than a certain amount of time. This event can be >> successively >> grabbed and managed by an user-level daemon such as acpid, blanking the >> screen, >> dimming the lcd-panel light ? la mac, etc... > >While functionality is extremely interesting does it really have >to be in kernel? I think so. While the X server grabs off any keyboard and mouse activity on its own, there is no such thing for the [read "all"] console[s]. Mouse movement (e.g. GPM) is actually implemented in the kernel, and screen blanking (the one controlled with "\e[9;x]") is too. -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] atl1: Attansic L1 ethernet driver
This is the latest submittal of the patchset providing support for the Attansic L1 gigabit ethernet adapter. This patchset is built against kernel version 2.6.20-rc5. This version incorporates all comments from: Christoph Hellwig: http://lkml.org/lkml/2007/1/11/43 http://lkml.org/lkml/2007/1/11/45 http://lkml.org/lkml/2007/1/11/48 http://lkml.org/lkml/2007/1/11/49 Jeff Garzik: http://lkml.org/lkml/2007/1/18/233 Many thanks to both for reviewing the driver. The monolithic version of this patchset may be found at: ftp://hogchain.net/pub/linux/attansic/kernel_driver/atl1-2.0.5-linux-2.6.20.rc5.patch.bz2 As a reminder, this driver is a modified version of the Attansic reference driver for the L1 ethernet adapter. Attansic has granted permission for its inclusion in the mainline kernel. This patchset contains: drivers/net/Kconfig | 11 + drivers/net/Makefile|1 + drivers/net/atl1/Makefile |2 + drivers/net/atl1/atl1.h | 288 + drivers/net/atl1/atl1_ethtool.c | 436 +++ drivers/net/atl1/atl1_hw.c | 728 drivers/net/atl1/atl1_hw.h | 965 +++ drivers/net/atl1/atl1_main.c| 2490 drivers/net/atl1/atl1_param.c | 223 9 files changed, 5144 insertions(+), 0 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.16.38
Ralf Baechle wrote: On Sun, Jan 21, 2007 at 06:37:24PM +0200, S.Çağlar Onur wrote: 21 Oca 2007 Paz tarihinde şunları yazmıştınız: RSS feed of the git tree: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=r I already mailed to webmaster _at_ kernel.org 2 days ago but still all RSS feeds gaves "Internal Server Error" kernel.org is not in quite the best shape currently due to the machines' massive overload, so this may take a little while to get fixed. Do note that www2.kernel.org has a load that is usually 1/20th of www1.kernel.org; apparently due to Microsoft DNS braindamage (which affects anyone whose ISP uses MS-DNS.) Using www2.kernel.org explicitly is likely to give you better performance. HOWEVER, performance is going to suck due to the measures we've had to take on the servers regardless, and it's entirely likely git-rss is totally broken. Again, we should have a dedicated git server in operation in about a month. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.16.38
On Sun, Jan 21, 2007 at 06:37:24PM +0200, S.Çağlar Onur wrote: > 21 Oca 2007 Paz tarihinde şunları yazmıştınız: > > RSS feed of the git tree: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=r > > I already mailed to webmaster _at_ kernel.org 2 days ago but still all RSS > feeds gaves "Internal Server Error" kernel.org is not in quite the best shape currently due to the machines' massive overload, so this may take a little while to get fixed. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.16.38
S.Çağlar Onur wrote: 21 Oca 2007 Paz tarihinde şunları yazmıştınız: RSS feed of the git tree: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=r I already mailed to webmaster _at_ kernel.org 2 days ago but still all RSS feeds gaves "Internal Server Error" We're aware of the problem, and it's almost certainly related either to the high loads we've had recently or to the necessary load-mitigation issues. Realistically, it probably won't be fixed until we have a dedicated git server in place, which is in process; it will probably be installed some time in February. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial port blues
H. Peter Anvin wrote: So write a kernel driver. It's not like we're locking anybody out. There is certainly enough Amateur Radio/Linux crossover that a kernel enhancement to support Amateur Radio is going to get frowned upon. Argh! Not only did the message go out twice, but that should have been "is *not* going to get frowned upon..." -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions triggered by XFS (since 2.6.18)
On Sunday, 21. January 2007 20:25, Paolo Ornati wrote: > On Sun, 21 Jan 2007 11:32:02 -0600 > Robert Hancock <[EMAIL PROTECTED]> wrote: > > > It looks like what you're getting is an actual NCQ write timing out. > > That makes the bisect result not very interesting since obviously it > > wouldn't have issued any NCQ writes before NCQ support was > > implemented. Seeing as how it's also an entirely different driver I > > imagine it's a different problem than what I've been looking at. > > > > Maybe that drive just has some issues with NCQ? I would be surprised > > at that with a Seagate though.. > > I don't know. It's a two years old ST380817AS. > > > # smartctl -a -d ata /dev/sda > > smartctl version 5.36 [x86_64-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen > Home page is http://smartmontools.sourceforge.net/ > > === START OF INFORMATION SECTION === > Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family > Device Model: ST380817AS > Serial Number:4MR08EK8 > Firmware Version: 3.42 > User Capacity:80,026,361,856 bytes > Device is:In smartctl database [for details use: -P show] > ATA Version is: 6 > ATA Standard is: ATA/ATAPI-6 T13 1410D revision 2 > Local Time is:Sun Jan 21 20:15:40 2007 CET > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x82) Offline data collection activity > was completed without error. > Auto Offline Data Collection: Enabled. > Self-test execution status: ( 0) The previous self-test routine > completed > without error or no self-test has ever > been run. > Total time to complete Offline > data collection: ( 430) seconds. > Offline data collection > capabilities: (0x5b) SMART execute Offline immediate. > Auto Offline data collection on/off > support. > Suspend Offline collection upon new > command. > Offline surface scan supported. > Self-test supported. > No Conveyance Self-test supported. > Selective Self-test supported. > SMART capabilities:(0x0003) Saves SMART data before entering > power-saving mode. > Supports SMART auto save timer. > Error logging capability:(0x01) Error logging supported. > No General Purpose Logging support. > Short self-test routine > recommended polling time: ( 1) minutes. > Extended self-test routine > recommended polling time: ( 47) minutes. > > SMART Attributes Data Structure revision number: 10 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED > WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 059 049 006Pre-fail Always > - 215927244 > 3 Spin_Up_Time0x0003 098 098 000Pre-fail Always > - 0 > 4 Start_Stop_Count0x0032 098 098 020Old_age Always > - 2182 > 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always > - 0 > 7 Seek_Error_Rate 0x000f 083 060 030Pre-fail Always > - 204305750 > 9 Power_On_Hours 0x0032 097 097 000Old_age Always > - 3494 > 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always > - 0 > 12 Power_Cycle_Count 0x0032 098 098 020Old_age Always > - 2541 > 194 Temperature_Celsius 0x0022 024 040 000Old_age Always > - 24 (Lifetime Min/Max 0/15) > 195 Hardware_ECC_Recovered 0x001a 059 049 000Old_age Always > - 215927244 > 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always > - 1 > 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline > - 1 > 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always > - 0 > 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline > - 0 > 202 TA_Increase_Count 0x0032 100 253 000Old_age Always > - 0 > > SMART Error Log Version: 1 > ATA Error Count: 12 (device log contains only the most recent five errors) > CR = Command Register [HEX] > FR = Features Register [HEX] > SC
Re: SATA exceptions with 2.6.20-rc5
On Sunday, 21. January 2007 19:01, Björn Steinbrink wrote: > On 2007.01.21 18:34:40 +0100, Chr wrote: > > I run those two in parallel: > while /bin/true; do ls -lR / > /dev/null 2>&1; done > while /bin/true; do echo 255 > /proc/sys/vm/drop_caches; sleep 1; done > > Not sure if running them in parallel is necessary, but I don't want to > change the test setup ;) Takes between 1 and 40 minutes to trigger it. > Most of the time it's around 15 minutes now, doing more random stuff in > addition to that seems to trigger it even easier (like reading mail, > rebuilding the kernel etc.). > > I'm down to 2 commits after 2.6.19 now, only bad kernels, so I tend to > say that 2.6.19 with 2.6.20-rc5's sata_nv.c will also fail for me, but I > thought I might finish bisection just to be sure. > > > But, this time it looks slightly different: > > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > > ata3.00: tag 0 cmd 0xec Emask 0x4 stat 0x40 err 0x0 (timeout) > > > > [Rest of the error message + SMART error snipped] > > I get the same exception every time, doesn't change for me. And neither > do I get any SMART errors or something. > > Thanks, > Björn Ok, you won't believe this... I opened my case and rewired my drives... And guess what, my second (aka the "good") HDD is now failing! I guess, my mainboard has a (but maybe two, or three :( ) "bad" sata-port(s)! But, one small question remains: when I opened my case, I saw that my drivers are pluged in SATA jack 1 and 2... The BIOS also says they're on 1 and 2. Now, Linux says they're on port 3 & 4! it's always ata3.00! "ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata3.00: tag 0 cmd 0xea Emask 0x4 stat 0x40 err 0x0 (timeout) ata3: soft resetting port ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/133 ata3: EH complete SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back" Thanks, Chr. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Junio C Hamano <[EMAIL PROTECTED]> wrote: > BTW, as the upcoming v1.5.0 release will introduce quite a bit of > surface changes (although at the really core it still is the old > git and old ways should continue to work), I am wondering if it > would help people to try out and find wrinkles before the real > thing for me to cut a tarball and a set of RPM packages. > > Comments? > > Also, in the same spirit of giving the release an early > exposure, here is the current draft of 1.5.0 release notes. > > -- >8 -- cut here -- >8 -- > > GIT v1.5.0 Release Notes (draft) > > > Old news > [...] > - There is a configuration variable core.legacyheaders that >changes the format of loose objects so that they are more >efficient to pack and to send out of the repository over git >native protocol, since v1.4.2. However, loose objects >written in the new format cannot be read by git older than >that version; people fetching from your repository using >older clients over dumb transports (e.g. http) using older >versions of git will also be affected. Huh? What are possible values of that variable? What happens if it is set/unset? I'd suppose that if it is set, you get the old format, but that isn't clear. > - Since v1.4.3, configuration repack.usedeltabaseoffset allows >packfile to be created in more space efficient format, which >cannot be read by git older than that version. Same as above. > The above two are not enabled by default and you explicitly have > to ask for them, because these two features make repositories > unreadable by older versions of git, and in v1.5.0 we still do > not enable them by default for the same reason. We will change > this default probably 1 year after 1.4.2's release, when it is > reasonable to expect everybody to have new enough version of > git. I don't see an upgrade path here that doesn't involve keeping cruft "new feature is on" variables around indefinitely... Why not just a repository version? [...] > Updates in v1.5.0 since v1.4.4 series > - > > * Index manipulation [...] > - git-add without any argument does not add everything >anymore. Use 'git-add .' instead. Also you can add >otherwise ignored files with an -f option. I suppose "git add ." works for 'adding everything' only at the top? > - git-add tries to be more friendly to users by offering an >interactive mode. Why not tell about "git add -i"? [...] > * Detached HEAD [...] > - After detaching your HEAD, you can go back to an existing >branch with usual "git checkout $branch". Also you can >start a new branch using "git checkout -b $newbranch". Where is such a branch rooted? > - You can even pull from other repositories, make merges and >commits while your HEAD is detached. Also you can use "git >reset" to jump to arbitrary commit. Does this leave you on that branch, or still in limbo? >Going back to undetached state by "git checkout $branch" can s/undetached/attached/ >lose the current stat you arrived in these ways, and "git >checkout" refuses when the detached HEAD is not pointed by >any existing ref (an existing branch, a remote tracking >branch or a tag). This safety can be overriden with "git >checkout -f $branch". What happens if there are changes in the tracked files? [...] > * Shallow clones > > - There is a partial support for 'shallow' repositories that >keeps only recent history. A 'shallow clone' is created by >specifying how deep that truncated history should be. A bit of detail on how to specify shallowness would be nice here... Very nice work, thanks! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
Geert Uytterhoeven wrote: Yeah, and Ethernet speed is measured in Mbps, not Mibps. Indeed. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT question
On Sunday 21 January 2007 13:09, Michael Tokarev wrote: > Denis Vlasenko wrote: > > On Saturday 20 January 2007 21:55, Michael Tokarev wrote: > >> Denis Vlasenko wrote: > >>> On Thursday 11 January 2007 18:13, Michael Tokarev wrote: > example, which isn't quite possible now from userspace. But as long as > O_DIRECT actually writes data before returning from write() call (as it > seems to be the case at least with a normal filesystem on a real block > device - I don't touch corner cases like nfs here), it's pretty much > THE ideal solution, at least from the application (developer) standpoint. > >>> Why do you want to wait while 100 megs of data are being written? > >>> You _have to_ have threaded db code in order to not waste > >>> gobs of CPU time on UP + even with that you eat context switch > >>> penalty anyway. > >> Usually it's done using aio ;) > >> > >> It's not that simple really. > >> > >> For reads, you have to wait for the data anyway before doing something > >> with it. Omiting reads for now. > > > > Really? All 100 megs _at once_? Linus described fairly simple (conceptually) > > idea here: http://lkml.org/lkml/2002/5/11/58 > > In short, page-aligned read buffer can be just unmapped, > > with page fault handler catching accesses to yet-unread data. > > As data comes from disk, it gets mapped back in process' > > address space. > > > This way read() returns almost immediately and CPU is free to do > > something useful. > > And what the application does during that page fault? Waits for the read > to actually complete? How it's different from a regular (direct or not) > read? The difference is that you block exactly when you try to access data which is not there yet, not sooner (potentially much sooner). If application (e.g. database) needs to know whether data is _really_ there, it should use aio_read (or something better, something which doesn't use signals. Do we have this 'something'? I honestly don't know). In some cases, evne this is not needed because you don't have any other things to do, so you just do read() (which returns early), and chew on data. If your CPU is fast enough and processing of data is light enough so that it outruns disk - big deal, you block in page fault handler whenever a page is not read for you in time. If CPU isn't fast enough, your CPU and disk subsystem are nicely working in parallel. With O_DIRECT, you alternate: "CPU is idle, disk is working" / "CPU is working, disk is idle". > Well, it IS different: now we can't predict *when* exactly we'll sleep waiting > for the read to complete. And also, now we're in an unknown-corner-case when > an I/O error occurs, too (I/O errors iteracts badly with things like mmap, and > this looks more like mmap than like actual read). > > Yes, this way we'll fix the problems in current O_DIRECT way of doing things - > all those rases and design stupidity etc. Yes it may work, provided those > "corner cases" like I/O errors problems will be fixed. What do you want to do on I/O error? I guess you cannot do much - any sensible db will shutdown itself. When your data storage starts to fail, it's pointless to continue running. You do not need to know which read() exactly failed due to bad disk. Filename and offset from the start is enough. Right? So, SIGIO/SIGBUS can provide that, and if your handler is of void (*sa_sigaction)(int, siginfo_t *, void *); style, you can get fd, memory address of the fault, etc. Probably kernel can even pass file offset somewhere in siginfo_t... > And yes, sometimes > it's not really that interesting to know when exactly we'll sleep actually > waiting for the I/O - during read or during some memory access... It differs from performance perspective, as dicussed above. > There may be other reasons to "want" those extra context switches. > I mentioned above that oracle doesn't use threads, but processes. You can still be multithreaded. The point is, with O_DIRECT you _are forced_ to_ be_ multithreaded, or else perfomance will suck. > > Assume that we have "clever writes" like Linus described. > > > > /* something like "caching i/o over this fd is mostly useless" */ > > /* (looks like this API is easier to transition to > > * than fadvise etc. - it's "looks like" O_DIRECT) */ > > fd = open(..., flags|O_STREAM); > > ... > > /* Starts writeout immediately due to O_STREAM, > > * marks buf100meg's pages R/O to catch modifications, > > * but doesn't block! */ > > write(fd, buf100meg, 100*1024*1024); > > And how do we know when the write completes? > > > /* We are free to do something useful in parallel */ > > sort(); > > .. which is done in another process, already started. You think "Oracle". But this application may very well be not Oracle, but diff, or dd, or KMail. I don't want to care. I want all big writes to be efficient, not just those done by Oracle. *Including* single threaded ones. > > Why we bothered to write Linux at
Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
On Sat, 20 Jan 2007, H. Peter Anvin wrote:
> David Schwartz wrote:
> > Talk about a cure worse than the disease! So you're saying that 256MB
> > flash
> > cards could be advertised as having 268.4MB? A 512MB RAM stick is
> > mislabelled and could correctly say 536.8MB? That's just plain craziness.
> >
> > Adopting IEC 60027-2 just replaces a set of well-understood problems
> > with
> > all new problems.
>
> Except that you're wrong above. Most 512 MB flash cards are less than 512
> MiB; most of them are, in fact, around 512 MB! RAM, of course, is
> consistently 512 MiB.
>
> This little tidbit discovered in the process of working on an application
> which required powers-of-two flash cards, and finding that one does have to
> use one size larger...
Yeah, and Ethernet speed is measured in Mbps, not Mibps.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Junio C Hamano <[EMAIL PROTECTED]> wrote: > Willy Tarreau <[EMAIL PROTECTED]> writes: > > Anything you can do to make tester's life easier will always slightly > > increase the number of testers. > > ... > > Pre-release tar.gz and rpms coupled with a freshmeat announcement should > > get you a bunch of testers and newcomers. This will give the new doc a > > real trial, and will help discover traps in which beginners often fall. > > One worry I had about releasing git-1.5.0-rc2-1.rpm and friends > just like the "official" ones was that people might have scripts > to automate downloading & updating of packages, and they may not > like to get "beta" installed for them. Then put them into a "testing" or "pre-release" directory... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCLUE3] flagging kernel interface changes
Jesper Juhl wrote: On 15/11/06, William D Waddington <[EMAIL PROTECTED]> wrote: I tried submitting a patch a while back: "[PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype" to add #define __PT_REGS to include/linux/interrupt.h to flag the change to the new interrupt handler prototype. It wasn't well received :( No big surprise. The #define wasn't my idea and I hadn't submitted a patch before. I wanted to see how the patch procedure worked, and hoped that the flag would be included so I could mod my drivers and move on... What I'm curious about is why flagging kernel/driver interface changes is considered a bad idea. From my point of view as a low-life out-of- tree driver maintainer, #ifdef NEW_INTERFACE #define #endif (w/maybe an #else...) is cleaner and safer than trying to track specific kernel versions in a multi-kernel-version driver. It seems that in some cases, the new interface has been, like HAVE_COMPAT_IOCTL for instance. I don't want to start an argument about "stable_api_nonsense" or the wisdom of out-of-tree drivers. Just curious about the - why - and whether it is indifference or antagonism toward drivers outside the fold. Or ??? I would say that one reason is that cluttering up the kernel with #ifdef's is ugly and annoying to maintain long-term. Especially when it's expected that anyone who changes in-kernel interfaces also fix up any user(s) of those interfaces, so the #ifdef's are pointless (ignoring out-of-tree code that is). Ah, but out-of-tree code is what I'm stuck w/maintaining. I wouldn't want to infest in-tree drivers w/#ifdef's either, but they are a fact of life in my world. And, lately, _really_ ugly version tests. If I had _my_ way, there would be a kernel_interface_change.h file that had an #define'd entry for _every_ kernel interface change within a major release series: /* * include/linux/interrupt.h interface change x.y.z * interrupt handler now takes 2 args */ #define INTERRUPT_H_CHANGE_X.Y.Z "interrupt handler now takes 2 args" or something. I understand that many (most?) kernel maintainers would prefer that all drivers be brought in-tree, and aren't particularly concerned when interface changes affect out-of-tree drivers. Respectfully, I suggest that world domination isn't quite the same thing as world dictatorship, and maybe the road to the former would be helped by a little less of the latter :) Rat-bastard out-of-tree maintainer takes refuge under desk Thanks, Bill -- William D Waddington Bainbridge Island, WA, USA [EMAIL PROTECTED] "Even bugs...are unexpected signposts on the long road of creativity..." - Ken Burtch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
Björn Steinbrink wrote:
All kernels were bad using that approach. So back to square 1. :/
Björn
OK guys, here's a new patch to try against 2.6.20-rc5:
Right now when switching between ADMA mode and legacy mode (i.e. when
going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just
set the ADMA GO register bit appropriately and continue with no delay.
It looks like in some cases the controller doesn't respond to this
immediately, it takes some nanoseconds for the controller's status
registers to reflect the change that was made. It's possible that if we
were trying to issue commands during this time, the controller might not
react properly. This patch adds some code to wait for the status
register to change to the state we asked for before continuing.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--- linux-2.6.20-rc5/drivers/ata/sata_nv.c 2007-01-19 19:18:53.0
-0600
+++ linux-2.6.20-rc5debug/drivers/ata/sata_nv.c 2007-01-21 13:35:17.0
-0600
@@ -509,14 +509,38 @@ static void nv_adma_register_mode(struct
{
void __iomem *mmio = nv_adma_ctl_block(ap);
struct nv_adma_port_priv *pp = ap->private_data;
- u16 tmp;
+ u16 tmp, status;
+ int count = 0;
if (pp->flags & NV_ADMA_PORT_REGISTER_MODE)
return;
+ status = readw(mmio + NV_ADMA_STAT);
+ while(!(status & NV_ADMA_STAT_IDLE) && count < 20) {
+ ndelay(50);
+ status = readw(mmio + NV_ADMA_STAT);
+ count++;
+ }
+ if(count == 20)
+ ata_port_printk(ap, KERN_WARNING,
+ "timeout waiting for ADMA IDLE, stat=0x%hx\n",
+ status);
+
tmp = readw(mmio + NV_ADMA_CTL);
writew(tmp & ~NV_ADMA_CTL_GO, mmio + NV_ADMA_CTL);
+ count = 0;
+ status = readw(mmio + NV_ADMA_STAT);
+ while(!(status & NV_ADMA_STAT_LEGACY) && count < 20) {
+ ndelay(50);
+ status = readw(mmio + NV_ADMA_STAT);
+ count++;
+ }
+ if(count == 20)
+ ata_port_printk(ap, KERN_WARNING,
+"timeout waiting for ADMA LEGACY, stat=0x%hx\n",
+status);
+
pp->flags |= NV_ADMA_PORT_REGISTER_MODE;
}
@@ -524,7 +548,8 @@ static void nv_adma_mode(struct ata_port
{
void __iomem *mmio = nv_adma_ctl_block(ap);
struct nv_adma_port_priv *pp = ap->private_data;
- u16 tmp;
+ u16 tmp, status;
+ int count = 0;
if (!(pp->flags & NV_ADMA_PORT_REGISTER_MODE))
return;
@@ -534,6 +559,18 @@ static void nv_adma_mode(struct ata_port
tmp = readw(mmio + NV_ADMA_CTL);
writew(tmp | NV_ADMA_CTL_GO, mmio + NV_ADMA_CTL);
+ status = readw(mmio + NV_ADMA_STAT);
+ while(((status & NV_ADMA_STAT_LEGACY) ||
+ !(status & NV_ADMA_STAT_IDLE)) && count < 20) {
+ ndelay(50);
+ status = readw(mmio + NV_ADMA_STAT);
+ count++;
+ }
+ if(count == 20)
+ ata_port_printk(ap, KERN_WARNING,
+ "timeout waiting for ADMA LEGACY clear and IDLE,
stat=0x%hx\n",
+ status);
+
pp->flags &= ~NV_ADMA_PORT_REGISTER_MODE;
}
Re: [Announce] GIT v1.5.0-rc2
Junio C Hamano wrote: One worry I had about releasing git-1.5.0-rc2-1.rpm and friends just like the "official" ones was that people might have scripts to automate downloading & updating of packages, and they may not like to get "beta" installed for them. I wonder if kernel.org machines are also affected... Put them in a different directory hierarchy if you don't want to make them installed. I know it's a bit late to ask, but if new on-disk format changes, isn't it time to bump the version to 2.0? It would be easier for many people to remember that GIT 1.X uses format version 1 and that GIT 2.X uses format version 2 with backwards compatibility with 1.X. I also think that 1.5 is much more different from 1.0 than a mid-term 2.0 would be from current 1.5. I think we could have gone either way (as you said, it is probably a bit too late to discuss this), but it should probably be Ok to stay at 1.X as long as these one-way-street format updates are turned off by default. And the above happened way before this round and people have hopefully been happily using. For example, v1.4.2 was done early August 2006. In general, though, I would agree that the major number should change if there is an incompatible change. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Introduce simple TRUE and FALSE boolean macros.
On Sun, 21 Jan 2007, Nicholas Miell wrote: > On Sun, 2007-01-21 at 05:03 -0500, Robert P. J. Day wrote: > > Introduce the TRUE and FALSE boolean macros so that everyone can > > stop re-inventing them, and remove the one occurrence in the > > source tree that clashes with that change. > If you're going to introduce true and false macros, you should > probably use the official all-lowercase C99 version. i'm going to try this one more time, and see if i can get my point across. *yes*, the *eventual* goal should be to use the official all-lowercase C99 versions of "true" and "false", and the patch i proposed is, in fact, the first step in getting there. by adding (temporarily) the definitions of TRUE and FALSE to types.h, you should then (theoretically) be able to delete over 100 instances of those same macros being *defined* throughout the source tree. you're not going to be deleting the hundreds and hundreds of *uses* of TRUE and FALSE (not yet, anyway) but, at the very least, by adding two lines to types.h, you can delete all those redundant *definitions* and make sure that nothing breaks. (it shouldn't, of course, but it's always nice to be sure.) *now*, once that's done, you can start going through the tree and doing the conversion from upper case to lower case, little by little, subsystem by subsystem. the predictable response will be, "you really should do that all at once." that's not going to happen, and you know it, and i know it. that kind of change would be too big, and too disruptive. so why not just add two macro defines, then delete over 100 lines of what are now redundant definitions, make sure nothing breaks, then move on to phase two. do we understand one another now? rday - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
