Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
On Sat, 9 Jun 2001, Dawson Engler wrote: > > > > Good point. Spinlocks (with the exception of read-read locks, of course) > > and semaphores will deadlock on recursive use, while the BKL has this > > "process usage counter" recursion protection. > > Actually, it did show up all over the place --- I'd just selected two > candidates to examine out of hundreds. (Checking call chains is > strenous, even when you know what you're looking for.) Sure. > > Dawson - the user-mode access part is probably _the_ most interesting from > > a lock checking standpoint, could you check doing the page fault case? > > Sure, it's a pretty interaction. To be sure about the rule: any *_user > call can be treated as an implicit invocation of do_page_fault? As a first approximation, yes. The exception cases are certain callers that use kernel addresses and set_fs(KERNEL_DS) in order to "fake" arguments to system calls etc, but I doubt they should need any special-casing. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
Andrew, Although I don't run Redhat, your response tells me that, even though I was feeling that it was a kernel problem, it could be a userspace issue, which I also suspected. Debian updated their nettools today, so I will see if that helps in any way. Thanks for your help. If you think of anything else that might be an issue, please let me know. Glenn C. Hofmann Andrew wrote: Date sent: Sun, 10 Jun 2001 11:35:53 +1000 From: Andrew Morton <[EMAIL PROTECTED]> Subject:Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1 To: [EMAIL PROTECTED] Copies to: [EMAIL PROTECTED] > "Glenn C. Hofmann" wrote: > > > > I have tried 2.4.5-pre2 up to 2.4.6-pre1 with the same results. > > Everything boots great and I can login fine. When I try to assign > > an IP via DHCP or ifconfig, the system sits and stares at me > > indefinitely. 2.4.5-pre4 didn't compile for me, but pre3 works fine > > and pre5 locks. There is keyboard response, and Alt-SysRq will tell > > me that it knows I want it to sync the disks, but won't actually do > > it. It will reboot, though. I can switch between terminals, but > > cannot type anything at the login prompt. > > > > The board is a Abit KT7-RAID. I have waited to see if this issue > > has been resolved and will recompile the newer kernels (AC and Linus > > flavours) to see if it has cleared up, but wanted to see if maybe > > there is something else I should look at. I can provide any more > > information that might help, so please let me know. Thanks in > > advance. > > There's a problem in some versions of `pump' where it gets > confused and ends up spinning indefinitely. If you're using > pump could you please try the latest RPM? > > If that doesn't help, and if you're unable to kill pump > with ^C, and if other virtual consoles are not responding then > it could be a kernel problem - try hitting sysrq-T and feeding > the resulting logs through `ksymoops -m System.map' > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message 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: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
Andrew, Although I don't run Redhat, your response tells me that, even though I was feeling that it was a kernel problem, it could be a userspace issue, which I also suspected. Debian updated their nettools today, so I will see if that helps in any way. Thanks for your help. Glenn C. Hofmann On Sunday, 10 June 2001 Andrew wrote: > "Glenn C. Hofmann" wrote: > > > > I have tried 2.4.5-pre2 up to 2.4.6-pre1 with the same results. > > Everything boots great and I can login fine. When I try to assign > > an IP via DHCP or ifconfig, the system sits and stares at me > > indefinitely. 2.4.5-pre4 didn't compile for me, but pre3 works fine > > and pre5 locks. There is keyboard response, and Alt-SysRq will tell > > me that it knows I want it to sync the disks, but won't actually do > > it. It will reboot, though. I can switch between terminals, but > > cannot type anything at the login prompt. > > > > The board is a Abit KT7-RAID. I have waited to see if this issue > > has been resolved and will recompile the newer kernels (AC and Linus > > flavours) to see if it has cleared up, but wanted to see if maybe > > there is something else I should look at. I can provide any more > > information that might help, so please let me know. Thanks in > > advance. > > There's a problem in some versions of `pump' where it gets > confused and ends up spinning indefinitely. If you're using > pump could you please try the latest RPM? > > If that doesn't help, and if you're unable to kill pump > with ^C, and if other virtual consoles are not responding then > it could be a kernel problem - try hitting sysrq-T and feeding > the resulting logs through `ksymoops -m System.map' > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message 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] sockreg2.4.5-05 inet[6]_create() register/unregistertable
On Sat, 9 Jun 2001, watermodem wrote: > Mike Galbraith wrote: > > > > On Thu, 7 Jun 2001, watermodem wrote: > > > > > "David S. Miller" wrote: > > > > > > > > George Bonser writes: > > > > > There is, of course, one basic problem with that argument. While you can say > > > > > (and probably rightly so) that such a change would not be included in Linus' > > > > > kernel, I think anyone is allowed to post a patch that might make it > > > > > possible to add protocols as modules. If anyone chooses to use it is each > > > > > individual's decision but you could not prevent ACME from creating a patch > > > > > that allows protocol modules as long as they distributed the patch. Also, I > > > > > know that you are allowed to distribute proprietary modules in binary form > > > > > but are there any restrictions on what function these modules can perform? > > > > > I don't remember seeing any such restrictions. > > > > > > > > People can post whatever patches which do whatever, sure. > > > > But this isn't what matters. > > > > > > > > What matters is the API under which a binary-only module may interface > > > > to the kernel. Linus specifies that only the module exports in his > > > > tree fall into this API. > > > > > > > > As I stated in another email, the allowance of binary-only kernel > > > > modules is a special exception to the licensing of the kernel made by > > > > Linus. The GPL by itself, does not allow this at all. > > > > > > > > Later, > > > > David S. Miller > > > > [EMAIL PROTECTED] > > > > > > David, > > > > > >What is your real problem with La Monte's Code. > > >I don't buy your more "blessed than thou" argument. > > >It is a typical response one normally sees in large > > >organizations from folk with "empires" to protect. > > >Coming from the "land of warring tribes" firm it is > > >a attitude I have seen often. My response is take > > >a vacation, chill out and reassess. > > > > What words would you like to put in his mouth to replace those he used? > > > > -Mike > No words. Just suggesting to calm down for awhile before getting > into a flame-war. I am old enough to know that nothing is lost by > considering your words before painting yourself into a corner you may > not want to occupy in the future. There is a rather amusing contradiction present in these new words.. your first words were ill chosen to the point of being offensive. I've said what I had to say, so consider yourself flamed. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.6-pre2 page_launder() improvements
[Request For Testers ... patch below]
Hi,
during my holidays I've written the following patch (forward-ported
to 2.4.6-pre2 and improved a tad today), which implements these
improvements to page_launder():
1) don't "roll over" inactive_dirty pages to the back of the
list, but reclaim them in something more resembling LRU
order; this is especially good when the system has tons
of inactive_dirty pages due to eg. background scanning
2) eliminate the infinite penalty clean pages had over dirty
pages by not scanning the complete inactive_dirty list and
letting real dirty pages build up near the front of the
list ... we flush them asynchronously when we have enough
of them
3) when going into the launder_loop, we scan a larger fraction
of the inactive_dirty list; under most workloads this means
we can always flush the dirty pages asynchronously because
we'll have clean, freeable pages in the part of the list we
only scan in the launder_loop
4) when we have only dirty pages and cannot free pages, we
remember this for the next run of page_launder() and won't
waste CPU by scanning pages without flushing them in the
launder loop (after maxlaunder goes negative)
5) this same logic is used to control when we use synchronous
IO; only when we cannot free any pages now do we wait on
IO, this stops kswapd CPU wastage under heavy write loads
6) the "sync" argument to page_launder() now means whether
we're _allowed_ to do synchronous IO or not ... page_launder()
is now smart enough to determine if we should use asynchronous
IO only or if we should wait on IO
This patch has given excellent results on my laptop and my
workstation here and seems to improve kernel behaviour in tests
quite a bit. I can play mp3's unbuffered during moderate write
loads or moderately heavy IO ;)
YMMV, please test it. If it works great for everybody I'd like
to get this improvement merged into the next -pre kernel.
regards,
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
diff -ur linux-2.4.6-pre2-virgin/include/linux/mm.h linux-2.4.6-pre2/include/linux/mm.h
--- linux-2.4.6-pre2-virgin/include/linux/mm.h Sun Jun 10 00:44:01 2001
+++ linux-2.4.6-pre2/include/linux/mm.h Sat Jun 9 23:19:54 2001
@@ -169,6 +169,7 @@
#define PG_inactive_clean 11
#define PG_highmem 12
#define PG_checked 13 /* kill me in 2.5.. */
+#define PG_marker 14
/* bits 21-29 unused */
#define PG_arch_1 30
#define PG_reserved31
@@ -242,6 +243,9 @@
#define PageInactiveClean(page)test_bit(PG_inactive_clean, &(page)->flags)
#define SetPageInactiveClean(page) set_bit(PG_inactive_clean, &(page)->flags)
#define ClearPageInactiveClean(page) clear_bit(PG_inactive_clean, &(page)->flags)
+
+#define PageMarker(page) test_bit(PG_marker, &(page)->flags)
+#define SetPageMarker(page)set_bit(PG_marker, &(page)->flags)
#ifdef CONFIG_HIGHMEM
#define PageHighMem(page) test_bit(PG_highmem, &(page)->flags)
diff -ur linux-2.4.6-pre2-virgin/include/linux/swap.h
linux-2.4.6-pre2/include/linux/swap.h
--- linux-2.4.6-pre2-virgin/include/linux/swap.hSun Jun 10 00:44:01 2001
+++ linux-2.4.6-pre2/include/linux/swap.h Sat Jun 9 23:19:54 2001
@@ -205,6 +205,16 @@
page->zone->inactive_dirty_pages++; \
}
+/* Like the above, but add us after the bookmark. */
+#define add_page_to_inactive_dirty_list_marker(page) { \
+ DEBUG_ADD_PAGE \
+ ZERO_PAGE_BUG \
+ SetPageInactiveDirty(page); \
+ list_add(&(page)->lru, marker_lru); \
+ nr_inactive_dirty_pages++; \
+ page->zone->inactive_dirty_pages++; \
+}
+
#define add_page_to_inactive_clean_list(page) { \
DEBUG_ADD_PAGE \
ZERO_PAGE_BUG \
diff -ur linux-2.4.6-pre2-virgin/mm/vmscan.c linux-2.4.6-pre2/mm/vmscan.c
--- linux-2.4.6-pre2-virgin/mm/vmscan.c Sun Jun 10 00:44:02 2001
+++ linux-2.4.6-pre2/mm/vmscan.cSun Jun 10 00:57:25 2001
@@ -407,7 +407,7 @@
/**
* page_launder - clean dirty inactive pages, move to inactive_clean list
* @gfp_mask: what operations we are allowed to do
- * @sync: should we wait synchronously for the cleaning of pages
+ * @sync: are we allowed to do synchronous IO in emergencies ?
*
* When this function is called, we are most likely low on free +
* inactive_clean pages. Since we want to refill those pages as
@@ -428,20 +428,54 @@
#define CAN_DO_BUFFERS (gfp_mask & __GFP_BUFFER)
int page_launder(int gfp_mask, int sync)
{
+ static int cannot_free_pages;
int launder_loop, maxscan, cleaned_pages, maxlaunder;
- struct list_head * page_lru;
+ struct list_head * page_lru, * marker_lru;
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregistertable
watermodem <[EMAIL PROTECTED]> said: [...] > He is discussing a theme with legal implications. (Legal and Slow tended > to be intertwined) I know what his position in the linux kernel > hierarchy is, and if he were in a corporation with that position he > could just say NO without any reason. But, linux development is > portrayed as something "open" and "of the people" not a closed corporate > offering. Now, if that is not the case, then just take out all the > flowery words from the license and replace it with the unstated but > defacto communist motto "What's mine is mine What's yours is mine!". > Then you have the Communist Linux vs the Capitalist M$. Definitely > polarizes issues but doesn't buy anything with folks who just want to > run a stable computer and not make it a political statement. I just don't understand what would give anybody the right to stuff any random junk into the official kernel "because it would be convenient for us", not respecting the view on the matter of the people who wrote it and so own the copyright to it in the end. If said "right" isn't granted, you go ahead and accuse them of being "comunists" wanting to take away your stuff as theirs when it is *exactly* the other way around... The licence on the kernel certainly gives you (or anybody else) the right to fork the kernel and make a "protocols are modules" version. Wish you luck getting it to be used by somebody else, and getting the help of the people in the know on fixing it when it breaks. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
> On Sat, 9 Jun 2001, Alexander Viro wrote: > > > > Another difference from spinlocks is that BKL is recursive. I'm > > actually surprised that it didn't show up first. > > Good point. Spinlocks (with the exception of read-read locks, of course) > and semaphores will deadlock on recursive use, while the BKL has this > "process usage counter" recursion protection. Actually, it did show up all over the place --- I'd just selected two candidates to examine out of hundreds. (Checking call chains is strenous, even when you know what you're looking for.) > And I suspect that the current checker doesn't realize that any user mode > access is equivalent to calling "do_page_fault()" from a call-chain > standpoint. > > Dawson - the user-mode access part is probably _the_ most interesting from > a lock checking standpoint, could you check doing the page fault case? Sure, it's a pretty interaction. To be sure about the rule: any *_user call can be treated as an implicit invocation of do_page_fault? Dawson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please test: workaround to help swapoff behaviour
"Bulent Abali" <[EMAIL PROTECTED]> writes: > >Bulent, > > > >Could you please check if 2.4.6-pre2+the schedule patch has better > >swapoff behaviour for you? > > Marcelo, > > It works as expected. Doesn't lockup the box however swapoff keeps burning > the CPU cycles. It took 4 1/2 minutes to swapoff about 256MB of swap > content. Shutdown took just as long. I was hoping that shutdown would > kill the swapoff process but it doesn't. It just hangs there. Shutdown > is the common case. Therefore, swapoff needs to be optimized for > shutdowns. > You could imagine users frustration waiting for a shutdown when there are > gigabytes in the swap. > > So to summarize, schedule patch is better than nothing but falls far short. > I would put it in 2.4.6. Read on. The fix is to kill the dead/orphaned swap pages before we get to swapoff. At shutdown time there is practically nothing active in swap, so this should speed things up tremendously. The dead swap pages need to be killed as soon as possible to keep us from wasting RAM and swap, and totally agravating whatever swapping situation is present. Once the dead swap pages problem is fixed it is time to optimize swapoff. > -- > > The problem is with the try_to_unuse() algorithm which is very inefficient. > I searched the linux-mm archives and Tweedie was on to this. This is what > he wrote: "it is much cheaper to find a swap entry for a given page than > to find the swap cache page for a given swap entry." And he posted a > patch http://mail.nl.linux.org/linux-mm/2001-03/msg00224.html > His patch is in the Redhat 7.1 kernel 2.4.2-2 and not in 2.4.5. > > But in any case I believe the patch will not work as expected. > It seems to me that he is calling the function check_orphaned_swap(page) > in the wrong place. He is calling the function while scanning the > active_list in refill_inactive_scan(). The problem with that is if you > wait > 60 seconds or longer the orphaned swap pages will move from active > to inactive lists. Therefore the function will miss the orphans in inactive > lists. Any comments? The analysis sounds about right. We should be killing most of these pages in free_pte. Or at the very least putting them on their own list that we can scan them effectively. Someone was creating a patch to that effect earlier. try_to_unuse is inefficient with respect to cpu usage but it is efficient with respect to swap usage. If you are doing this on a running machine where you are removing a swap you don't want an algorithm that increases your need for swap. All of the trivial transformations of try_to_unuse have the property of breaking the sharing of swap pages. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] security rules? (and 2.4.5-ac4 security bug)
> Indeed; the bug in the uuid_strategy which you pointed out in the > random driver wasn't caused by the fact that we were using a > user-specified length (since the length was being capped to a maximum > value of 16). The security bug was that the test was done on a signed > value, and copy_to_user() takes an unsigned value. > > So your checker found a real bug, but it wasn't the one that the > checker thought it was. :-) No, it was the bug the checker thought it was: a signed integer from user space that had only been upper-bound checked. If the value had been unsigned, or had been checked in a range lower_bound < x < upper_bound there woulnd't have been a message. But I certainly concede that the message could be more informative. Dawson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: checker suggestion
> Struct padding is a problem. Really, there shouldn't be any > implicit padding. This causes: > > 1. security leaks when such structs are copied to userspace >(the implicit padding is uninitialized, and so may contain >a chunk of somebody's private key or password) > > 2. bloat, when struct members could be reordered to eliminate >the need for padding (1) is a great point. One of the first extensions in our first system automatically reordered structure fields to minimize padding (your second point), but we'd totally missed the security point. Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] truncate_inode_pages
Daniel Phillips wrote:
>
> This is easy, just set the list head to the page about to be truncated.
Works for me.
--- linux-2.4.5/mm/filemap.cMon May 28 13:31:49 2001
+++ linux-akpm/mm/filemap.c Sun Jun 10 11:29:19 2001
@@ -235,12 +235,13 @@
/* Is one of the pages to truncate? */
if ((offset >= start) || (*partial && (offset + 1) == start)) {
+ list_del(head);
+ list_add_tail(head, curr);
if (TryLockPage(page)) {
page_cache_get(page);
spin_unlock(_lock);
wait_on_page(page);
- page_cache_release(page);
- return 1;
+ goto out_restart;
}
page_cache_get(page);
spin_unlock(_lock);
@@ -252,11 +253,14 @@
truncate_complete_page(page);
UnlockPage(page);
- page_cache_release(page);
- return 1;
+ goto out_restart;
}
}
return 0;
+out_restart:
+ page_cache_release(page);
+ spin_lock(_lock);
+ return 1;
}
@@ -273,15 +277,18 @@
{
unsigned long start = (lstart + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
unsigned partial = lstart & (PAGE_CACHE_SIZE - 1);
+ int complete;
-repeat:
spin_lock(_lock);
- if (truncate_list_pages(>clean_pages, start, ))
- goto repeat;
- if (truncate_list_pages(>dirty_pages, start, ))
- goto repeat;
- if (truncate_list_pages(>locked_pages, start, ))
- goto repeat;
+ do {
+ complete = 1;
+ while (truncate_list_pages(>clean_pages, start, ))
+ complete = 0;
+ while (truncate_list_pages(>dirty_pages, start, ))
+ complete = 0;
+ while (truncate_list_pages(>locked_pages, start, ))
+ complete = 0;
+ } while (!complete);
spin_unlock(_lock);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
"Glenn C. Hofmann" wrote: > > I have tried 2.4.5-pre2 up to 2.4.6-pre1 with the same results. Everything boots > great and I can login fine. When I try to assign an IP via DHCP or ifconfig, the >system > sits and stares at me indefinitely. 2.4.5-pre4 didn't compile for me, but pre3 >works fine > and pre5 locks. There is keyboard response, and Alt-SysRq will tell me that it >knows I > want it to sync the disks, but won't actually do it. It will reboot, though. I can >switch > between terminals, but cannot type anything at the login prompt. > > The board is a Abit KT7-RAID. I have waited to see if this issue has been resolved >and > will recompile the newer kernels (AC and Linus flavours) to see if it has cleared >up, but > wanted to see if maybe there is something else I should look at. I can provide any >more > information that might help, so please let me know. Thanks in advance. There's a problem in some versions of `pump' where it gets confused and ends up spinning indefinitely. If you're using pump could you please try the latest RPM? If that doesn't help, and if you're unable to kill pump with ^C, and if other virtual consoles are not responding then it could be a kernel problem - try hitting sysrq-T and feeding the resulting logs through `ksymoops -m System.map' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Fix compiles warnings in 2.4.6pre2
This patch fixes compile warnings when using gcc 3.0 cvs snapshots. It
makes the following changes:
- Removes warnings about trigraphs (done by patching the Makefile in top
directory
- changes text at the end of #endif statements to comments
- fixes warnings about use of labels at the end of compound statements
- fixes a warning about no newline at the end of net/khttpd/security.h
Let me know if you have any questions or comments.
Rich
diff -urN -X dontdiff linux/Makefile rb/Makefile
--- linux/Makefile Fri Jun 8 20:07:49 2001
+++ rb/Makefile Sat Jun 9 11:15:02 2001
@@ -87,7 +87,7 @@
CPPFLAGS := -D__KERNEL__ -I$(HPATH)
-CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
-fno-strict-aliasing
+CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
+ -fomit-frame-pointer -fno-strict-aliasing
AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)
#
diff -urN -X dontdiff linux/arch/i386/math-emu/fpu_trig.c
rb/arch/i386/math-emu/fpu_trig.c
--- linux/arch/i386/math-emu/fpu_trig.c Fri Apr 6 12:42:47 2001
+++ rb/arch/i386/math-emu/fpu_trig.cSat Jun 9 10:56:54 2001
@@ -1543,6 +1543,7 @@
EXCEPTION(EX_INTERNAL | 0x116);
return;
#endif /* PARANOID */
+ break;
}
}
else if ( (st0_tag == TAG_Valid) || (st0_tag == TW_Denormal) )
diff -urN -X dontdiff linux/drivers/atm/fore200e.c rb/drivers/atm/fore200e.c
--- linux/drivers/atm/fore200e.cFri Feb 9 14:30:22 2001
+++ rb/drivers/atm/fore200e.c Sat Jun 9 10:57:44 2001
@@ -439,6 +439,7 @@
case FORE200E_STATE_BLANK:
/* nothing to do for that state */
+ break;
}
}
diff -urN -X dontdiff linux/drivers/media/video/tuner.c
rb/drivers/media/video/tuner.c
--- linux/drivers/media/video/tuner.c Mon Feb 19 17:43:36 2001
+++ rb/drivers/media/video/tuner.c Sat Jun 9 10:59:55 2001
@@ -558,6 +558,7 @@
#endif
default:
/* nothing */
+ break;
}
return 0;
diff -urN -X dontdiff linux/drivers/net/tokenring/ibmtr.c
rb/drivers/net/tokenring/ibmtr.c
--- linux/drivers/net/tokenring/ibmtr.c Tue Mar 20 15:05:00 2001
+++ rb/drivers/net/tokenring/ibmtr.cSat Jun 9 11:01:08 2001
@@ -1185,7 +1185,7 @@
isa_writeb(~CMD_IN_SRB, ti->mmio + ACA_OFFSET +
ACA_RESET + ISRA_ODD);
isa_writeb(~SRB_RESP_INT, ti->mmio + ACA_OFFSET +
ACA_RESET + ISRP_ODD);
- skip_reset:
+ skip_reset:;
} /* SRB response */
if (status & ASB_FREE_INT) { /* ASB response */
diff -urN -X dontdiff linux/drivers/net/wan/hdlc.c rb/drivers/net/wan/hdlc.c
--- linux/drivers/net/wan/hdlc.cWed Apr 18 16:40:07 2001
+++ rb/drivers/net/wan/hdlc.c Sat Jun 9 11:01:51 2001
@@ -1082,7 +1082,9 @@
}
break;
- default:/* to be defined */
+ default:
+ /* to be defined */
+ break;
}
dev_kfree_skb(skb);
diff -urN -X dontdiff linux/drivers/net/wan/sdla_fr.c
rb/drivers/net/wan/sdla_fr.c
--- linux/drivers/net/wan/sdla_fr.c Fri Apr 20 13:54:22 2001
+++ rb/drivers/net/wan/sdla_fr.cSat Jun 9 11:02:14 2001
@@ -4435,7 +4435,8 @@
trigger_fr_poll(dev);
break;
- default: // ARP's and RARP's -- Shouldn't happen.
+ default:
+ break; // ARP's and RARP's -- Shouldn't happen.
}
return 0;
diff -urN -X dontdiff linux/drivers/net/wan/sdla_x25.c
rb/drivers/net/wan/sdla_x25.c
--- linux/drivers/net/wan/sdla_x25.cFri Apr 20 13:54:22 2001
+++ rb/drivers/net/wan/sdla_x25.c Sat Jun 9 11:02:27 2001
@@ -3108,7 +3108,7 @@
case 0x08: /* modem failure */
#ifndef MODEM_NOT_LOG
printk(KERN_INFO "%s: modem failure!\n", card->devname);
-#endif MODEM_NOT_LOG
+#endif /* MODEM_NOT_LOG */
api_oob_event(card,mb);
break;
diff -urN -X dontdiff linux/drivers/scsi/NCR53c406a.c
rb/drivers/scsi/NCR53c406a.c
--- linux/drivers/scsi/NCR53c406a.c Tue Jun 5 15:49:09 2001
+++ rb/drivers/scsi/NCR53c406a.cSat Jun 9 11:06:38 2001
@@ -221,7 +221,7 @@
(void *)0xc8000
};
#define ADDRESS_COUNT (sizeof( addresses ) / sizeof( unsigned ))
-#endif USE_BIOS
+#endif /* USE_BIOS */
/* possible i/o port addresses */
static unsigned short ports[] =
@@ -244,7 +244,7 @@
{ "Copyright (C) Acculogic, Inc.\r\n2.8M Diskette Extension Bios ver
4.04.03 03/01/1993", 61, 82 },
};
#define SIGNATURE_COUNT (sizeof( signatures ) / sizeof( struct signature ))
-#endif USE_BIOS
+#endif /* USE_BIOS */
/* */
@@ -347,7 +347,7 @@
return tmp;
}
-#endif USE_DMA
+#endif /*
[patch] sys_modify_ldt extension (default_ldt)
Hi,
I am trying to integrate binfmt_xout.c into kernel 2.4 as part of the
linux-abi project (formerly known as iBCS). For old Xenix 286 binaries the
lcall7 gate needs to part of the LDT.
In kernels 2.0 sys_modify_ldt(0,...) used to return the default_ldt (with
lcall7 gate) if there were no segments set up. This behaviour changed in
kernels 2.2 . As a result of a discussion with Linus, David Bruce wrote a
patch for binfmt_xout.c tweaking with gdt and current->tss.ldt to get the
address of default_ldt. This patch does not work any more with kernels 2.4
as tss vanished from task_struct.
I do see 4 ways to cope with this problem:
a) extend sys_modify_ldt with a function to retrieve the default_ldt. I did
this for testing (see attached diff for arch/i386/kernel/ldt.c ).
b) do some work an Davids patch but this is kind of magic for me :-)
(see attached default_ldt patch)
c) loose the option to compile binfmt_xout (and the rest of linux-abi) as
module and simply use the symbol default_ldt. I dint't try that.
d) Forget about those old fashioned 286 binaries. This option will make some
linux users feel sad, as they run these progs for their daily business.
Joerg
--
--
Joerg Ahrens _/
Koenigsberger Strasse 32_/_/
31226 Peine _/ _/
Tel.: 05171/57308 _/_/_/_/_/
e-mail: [EMAIL PROTECTED]_/_/_/_/ _/
--
--- linux-2.4.0/arch/i386/kernel/ldt.c Fri Dec 29 23:07:20 2000
+++ linux-2.4.0.i/arch/i386/kernel/ldt.cSat Jun 9 22:48:46 2001
@@ -44,7 +44,24 @@
out:
return err;
}
+static int read_default_ldt(void * ptr, unsigned long bytecount)
+{
+ int err;
+ unsigned long size;
+ void *address;
+
+ err = 0;
+ address = _ldt[0];
+ size = sizeof(struct desc_struct);
+ if (size > bytecount)
+ size = bytecount;
+
+ err = size;
+ if (copy_to_user(ptr, address, size))
+ err = -EFAULT;
+ return err;
+}
static int write_ldt(void * ptr, unsigned long bytecount, int oldmode)
{
struct mm_struct * mm = current->mm;
@@ -156,6 +173,9 @@
break;
case 1:
ret = write_ldt(ptr, bytecount, 1);
+ break;
+ case 2:
+ ret = read_default_ldt(ptr, bytecount);
break;
case 0x11:
ret = write_ldt(ptr, bytecount, 0);
struct desc_struct def_ldt;
unsigned long *lp, *lp2;
asm volatile ( "sgdt __gdt+2" );
lp = (unsigned long *)(__gdt[1] + current->tss.ldt );
lp2 = (unsigned long *)(((*lp >> 16) & 0x)
| (*(lp+1) & 0xff00)
| ((*(lp+1) << 16) & 0x00ff));
def_ldt.a = *lp2;
def_ldt.b = *(lp2+1);
Re: Kernel 2.4.6-pre2 patch buglet
> Is it me or does this patch forget to change the kernel version? ;-) > make menuconfig reports pre1 still.. oh well no biggie.. yes, this is a mistake. the Makefile had not been updated. -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.4.6-pre2 patch buglet
Is it me or does this patch forget to change the kernel version? ;-) make menuconfig reports pre1 still.. oh well no biggie.. Shawn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] man-pages 1.38
New: man-pages 1.38, with for the first time over 1000 pages. Undocumented system calls include: rt_sigreturn, rt_sigaction, rt_sigprocmask, rt_sigpending, rt_sigtimedwait, rt_sigqueueinfo, rt_sigsuspend, sigaltstack, getpmsg, putpmsg, ugetrlimit, mmap2, madvise. Contributions are welcome. Andries - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Probable endianess problem in TLAN driver
[EMAIL PROTECTED] said: > Riley Williams writes: > > Even if that wasn't true, aren't the above all self-recursive > > definitions that would prevent anything calling them from compiling? > Yes, it looks that way. cpp doesn't recurse. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ess maestro, support for hardware volume control
> BTW, what is the officially approved way to open a device on a > dynamic misc minor? Reading /proc/misc for the minor number, Ask for minor 0 I believe, then load the module then see what you got. > then mknod'ing a device and opening it seems to me to have a > nasty race condition, am I missing something here? Ultimately if its a device of its own it probably wants to be part of the input device frame work - as for example the volume knob on my USB speakers is - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sockreg2.4.5-05 inet[6]_create() register/unregistertable
On Sat, 9 Jun 2001, watermodem wrote: > He is discussing a theme with legal implications. (Legal and Slow tended > to be intertwined) I know what his position in the linux kernel > hierarchy is, and if he were in a corporation with that position he > could just say NO without any reason. But, linux development is > portrayed as something "open" and "of the people" not a closed corporate > offering. Now, if that is not the case, then just take out all the > flowery words from the license and replace it with the unstated but > defacto communist motto "What's mine is mine What's yours is mine!". Pot. Kettle. Black. You are one who tries to tell other people what can be done with their code. With all my personal dislike of GPL (I use it if the project I'm working on does, but I won't use it for anything else), Dave _has_ right to choose the license he likes and you'd bloody better respect that. Author has absolute right to set the conditions for using his thing. If they are unacceptable for you - nobody forces you to use it. Any whining about that places you on the level of Napster wankers. Now, bugger off - go play with "social hackers" or something... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] truncate_inode_pages
On Saturday 09 June 2001 19:40, Alexander Viro wrote:
> > takes 45 seconds CPU time due to the O(clean * dirty) algorithm in
> > truncate_inode_pages(). The machine is locked up for the duration.
> > The patch reduces this to 20 milliseconds via an O(clean + dirty)
> > algorithm.
>
> Unfortunately, it's _not_ O(clean + dirty).
>
> > + while (truncate_list_pages(>clean_pages, start,
> > )) { + spin_lock(_lock);
> > + complete = 0;
> > + }
>
> Cool. Now think what happens if pages with large indices are in the
> very end of list. Half of them. You skip clean/2 pages on each of
> clean/2 passes. Hardly a linear behaviour - all you need is a
> different program to trigger it.
>
> Now, having a separate pass that would reorder the pages on list,
> moving the to-kill ones in the beginning might help.
This is easy, just set the list head to the page about to be truncated.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ess maestro, support for hardware volume control
> I now have a patch that will output the hwv buttons pressed (up, > down, mute) to a new dynamically allocated misc device as letters > u, d, m, instead of directly modifying the mixer. Anyone want > that? It's more flexible than either the patch that's currently > in -ac or Lukas's patch, but you need a little userspace daemon > for it to do anything useful. hmm.. how do the alsa guys deal with hw volume? I'm not sure I like adding more stuff to the OSS API. -- zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregistertable
Mike Galbraith wrote: > > On Thu, 7 Jun 2001, watermodem wrote: > > > "David S. Miller" wrote: > > > > > > George Bonser writes: > > > > There is, of course, one basic problem with that argument. While you can say > > > > (and probably rightly so) that such a change would not be included in Linus' > > > > kernel, I think anyone is allowed to post a patch that might make it > > > > possible to add protocols as modules. If anyone chooses to use it is each > > > > individual's decision but you could not prevent ACME from creating a patch > > > > that allows protocol modules as long as they distributed the patch. Also, I > > > > know that you are allowed to distribute proprietary modules in binary form > > > > but are there any restrictions on what function these modules can perform? > > > > I don't remember seeing any such restrictions. > > > > > > People can post whatever patches which do whatever, sure. > > > But this isn't what matters. > > > > > > What matters is the API under which a binary-only module may interface > > > to the kernel. Linus specifies that only the module exports in his > > > tree fall into this API. > > > > > > As I stated in another email, the allowance of binary-only kernel > > > modules is a special exception to the licensing of the kernel made by > > > Linus. The GPL by itself, does not allow this at all. > > > > > > Later, > > > David S. Miller > > > [EMAIL PROTECTED] > > > > David, > > > >What is your real problem with La Monte's Code. > >I don't buy your more "blessed than thou" argument. > >It is a typical response one normally sees in large > >organizations from folk with "empires" to protect. > >Coming from the "land of warring tribes" firm it is > >a attitude I have seen often. My response is take > >a vacation, chill out and reassess. > > What words would you like to put in his mouth to replace those he used? > > -Mike No words. Just suggesting to calm down for awhile before getting into a flame-war. I am old enough to know that nothing is lost by considering your words before painting yourself into a corner you may not want to occupy in the future. He is discussing a theme with legal implications. (Legal and Slow tended to be intertwined) I know what his position in the linux kernel hierarchy is, and if he were in a corporation with that position he could just say NO without any reason. But, linux development is portrayed as something "open" and "of the people" not a closed corporate offering. Now, if that is not the case, then just take out all the flowery words from the license and replace it with the unstated but defacto communist motto "What's mine is mine What's yours is mine!". Then you have the Communist Linux vs the Capitalist M$. Definitely polarizes issues but doesn't buy anything with folks who just want to run a stable computer and not make it a political statement. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message 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: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
On Sat, 9 Jun 2001, Linus Torvalds wrote: > On Sat, 9 Jun 2001, Alexander Viro wrote: > > > > True, but... I can easily see the situation when ->foo() and ->bar() > > both call a helper function which needs BKL for a small piece of code. > > I'd hope that we can fix the small helper functions to not need BKL - > there are already many circumstances where you can't use the BKL anyway > (ie you already hold a spinlock - I'd really like to have the rule that > the BKL is the "outermost" of all spinlocks, as we could in theory some > day use it as a point to schedule away on BKL contention). > > > ObUnrelated: fs/super.c is getting to the point where it naturally > > falls into two files - one that deals with mount cache and all things > > vfsmount-related, mount tree manipulations, etc. and another that deals > > with superblocks. Mind if I split the thing? > > Sure. As long as there is some sane naming and not too many new non-static > functions. Maybe just "fs/mount.c" for the vfsmount caches etc. Umm... In the final variant of patch all interaction is done by alloc_vfsmnt() and set_devname() on one side and kill_super(), do_kern_mount() and do_remount_sb() on another. That is, aside of the currently public functions (actually, some of them are gone - kern_umount is #defined to mntput and kern_mount became a trivial inlined wrapper around do_kern_mount, change_root is gone, etc.). In my variant it was called fs/namespace.c, basically since I prefer the names along the line "what does it deal with" (answer: user-visible namespace) to "what action is done here" ones, especially since mount(2) is not the only syscall exported (pivot_root(2) and umount(2) are also handled here). After all, inode.c, dcache.c, buffer.c, locks.c, devices.c, etc. are named that way. OTOH, open.c and namei.c are not, so... Up to you - my preference would be a noun and namespace looks better than next contender (mntcache), but that's your call - filenames in core kernel... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ess maestro, support for hardware volume control
Alan Cox <[EMAIL PROTECTED]> writes: > > this patch applies to (at least) 2.4.3 up to and including 2.4.6-pre2. > > It enables the hardware volume control feature of the maestro. > > it doesnt apply to the current version of the maestro driver (2.4.5-ac) > however. I think it is clashing with the docking station support Yeah, it does--I included support for the hwv control in the docking patch. I used a different technique though because I couldn't get the technique used by Lukas's patch to work properly for me. I now have a patch that will output the hwv buttons pressed (up, down, mute) to a new dynamically allocated misc device as letters u, d, m, instead of directly modifying the mixer. Anyone want that? It's more flexible than either the patch that's currently in -ac or Lukas's patch, but you need a little userspace daemon for it to do anything useful. BTW, what is the officially approved way to open a device on a dynamic misc minor? Reading /proc/misc for the minor number, then mknod'ing a device and opening it seems to me to have a nasty race condition, am I missing something here? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
On Sat, 9 Jun 2001, Alexander Viro wrote: > > True, but... I can easily see the situation when ->foo() and ->bar() > both call a helper function which needs BKL for a small piece of code. I'd hope that we can fix the small helper functions to not need BKL - there are already many circumstances where you can't use the BKL anyway (ie you already hold a spinlock - I'd really like to have the rule that the BKL is the "outermost" of all spinlocks, as we could in theory some day use it as a point to schedule away on BKL contention). > ObUnrelated: fs/super.c is getting to the point where it naturally > falls into two files - one that deals with mount cache and all things > vfsmount-related, mount tree manipulations, etc. and another that deals > with superblocks. Mind if I split the thing? Sure. As long as there is some sane naming and not too many new non-static functions. Maybe just "fs/mount.c" for the vfsmount caches etc. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
In article <[EMAIL PROTECTED]>, David Woodhouse <[EMAIL PROTECTED]> wrote: > >Obtaining a read lock twice can deadlock too, can't it? If it does (with spinlocks), then that's an implementation bug (which might well be there). We depend on the read-lock being recursive in a lot of places, notably the fact that we don't disable interrupts while holding read-locks if we know that the interrupt routines only take a read-lock. > A B > read_lock() > write_lock() > ...sleeps... > read_lock() > ...sleeps... > >Or do we not make new readers sleep if there's a writer waiting? The writer-waiter should not be spinning with the write lock held. Note that the blocking versions are different, and I explicitly meant only the read-spinlocks, not read-semaphores. For the semaphores I think your schenario is indeed correct. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please test: workaround to help swapoff behaviour
>Bulent, > >Could you please check if 2.4.6-pre2+the schedule patch has better >swapoff behaviour for you? Marcelo, It works as expected. Doesn't lockup the box however swapoff keeps burning the CPU cycles. It took 4 1/2 minutes to swapoff about 256MB of swap content. Shutdown took just as long. I was hoping that shutdown would kill the swapoff process but it doesn't. It just hangs there. Shutdown is the common case. Therefore, swapoff needs to be optimized for shutdowns. You could imagine users frustration waiting for a shutdown when there are gigabytes in the swap. So to summarize, schedule patch is better than nothing but falls far short. I would put it in 2.4.6. Read on. -- The problem is with the try_to_unuse() algorithm which is very inefficient. I searched the linux-mm archives and Tweedie was on to this. This is what he wrote: "it is much cheaper to find a swap entry for a given page than to find the swap cache page for a given swap entry." And he posted a patch http://mail.nl.linux.org/linux-mm/2001-03/msg00224.html His patch is in the Redhat 7.1 kernel 2.4.2-2 and not in 2.4.5. But in any case I believe the patch will not work as expected. It seems to me that he is calling the function check_orphaned_swap(page) in the wrong place. He is calling the function while scanning the active_list in refill_inactive_scan(). The problem with that is if you wait 60 seconds or longer the orphaned swap pages will move from active to inactive lists. Therefore the function will miss the orphans in inactive lists. Any comments? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem sis 7001usb-controller & framebuffer, bug?
Hello!
I have a notebook with this sis 7001 usb-controller and sis 630
chipset.(shared memory 8mb), motherboard uniwill 340s2.
Kernel 2.2.x 2.4.1 -2.4.5
X-winows 3.x -4x.
Many low-cost notebooks have this chipset.
All works fine, like my usb-webcam, usb-scanner and my usb-zip-drive with
usb-ohci driver and the other required drivers, but only without framebuffer.
I need framebuffer,because there is no support from Xfree86 for my
Tft LCD yet.
When i use the shell,zip-drive works very stable, no errors.
When i use this frambuffer-support & X-Windows all works, but usb-devices
are crashes after short time off running..
When i use the X-server without framebuffer, i can only use 640x480 for
testing with bad display, but all usb devices works without any Errors and
very stable.
I have no Io-or Int. conflicts.
It looks like a timing problem for me, because of this problematic sis 7001,
shared memory and framebuffer.
I tested a lot, but no succes.
All devices working stable on my Destop-machines.
I don´t know, how i resolve this strange problem with using framebuffering
and usb.
Kernel-messages from my zip-drive with framebuffering
kernel: bread in fat_access failed
Jun 9 20:04:42 pc3workstation kernel: I/O error: dev 08:01, sector 120
Jun 9 20:04:42 pc3workstation kernel: bread in fat_access failed
Jun 9 20:04:42 pc3workstation kernel: I/O error: dev 08:01, sector 120
Jun 9 20:04:42 pc3workstation kernel: bread in fat_access failed
Jun 9 20:04:42 pc3workstation kernel: I/O error: dev 08:01, sector 23822
Jun 9 20:04:42 pc3workstation kernel: I/O error: dev 08:01, sector 23822
Jun 9 20:05:06 pc3workstation kernel: I/O error: dev 08:01, sector 1556
Kernel-messages from my mustek-scanner
Unable to handle kernel NULL pointer dereJun 7 13:58:21 pc3workstation
kernel: printing eip:
Jun 7 13:58:21 pc3workstation kernel: c01b8fed
Jun 7 13:58:21 pc3workstation kernel: *pde =
Jun 7 13:58:21 pc3workstation kernel: Oops:
Jun 7 13:58:21 pc3workstation kernel: CPU:0
Jun 7 13:58:21 pc3workstation kernel: EIP:0010:[]
Jun 7 13:58:21 pc3workstation kernel: EFLAGS: 00010286
Jun 7 13:58:21 pc3workstation kernel: eax: 001c ebx: 09fa ecx:
cd68Jun 7 13:58:21 pc3workstation kernel: esi: cd687f20 edi: cd687f30
ebp: Jun 7 13:58:21 pc3workstation kernel: ds: 0018 es: 0018 ss: 0018
Jun 7 13:58:21 pc3workstation kernel: Process xsane (pid: 630,
stackpage=cd6870Jun 7 13:58:21 pc3workstation kernel: Stack: c01b9111
ce7993a0 09fa cefd65cJun 7 13:58:21 pc3workstation kernel:
cd687f20 cd88c000 cd687f2Jun 7 13:58:21 pc3workstation kernel:
cd686000 cd687f2Jun 7 13:58:21 pc3workstation kernel:
Call Trace: [] [] [http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
On Sat, 9 Jun 2001, Linus Torvalds wrote: > Anyway, in a 2.5.x timeframe we should probably make sure that we do not > have the need for a recursive BKL any more. That shouldn't be that hard to > fix, especially with help from CHECKER to verify that we didn't forget > some case. True, but... I can easily see the situation when ->foo() and ->bar() both call a helper function which needs BKL for a small piece of code. ->foo() callers take BKL (and it's choke-full of places that still need BKL, anyway). ->bar() is called without BKL. Moreover, grabbing BKL over the whole helper is a massive overkill. ObUnrelated: fs/super.c is getting to the point where it naturally falls into two files - one that deals with mount cache and all things vfsmount-related, mount tree manipulations, etc. and another that deals with superblocks. Mind if I split the thing? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext3 kernel RPMS (2.4.5 & 2.2.19)
Go to gkernel on sourceforge or to Andrew Morton's WWW site: http://www.uow.edu.au/~andrewm/linux/ext3/ On Sat, 9 Jun 2001, P.A.M. van Dam wrote: > On Fri, Jun 08, 2001 at 03:23:16PM -0600, Peter J. Braam wrote: > > Hi, > > > > Mostly for my own use, I prepared two kernel RPM's with Ext3 in them. > > > > Versions: > > 2.2.19 + 0.0.7a > > 2.4.5 + 0.0.6 > > > > PLEASE USE THESE AT YOUR OWN RISK - THEY CONTAIN EXPERIMENTAL FILE SYSTEM > > CODE. > > - Peter J. Braam - > > http://www.clusterfilesystem.com > > Ext3 for 2.4 kernels. Great. It's probably been asked before, but where can I > find the ext3 patch for the 2.4 kernels? > > Thanks in advance! > > Best regards, > > Pascal > > > > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message 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: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
[EMAIL PROTECTED] said: > Good point. Spinlocks (with the exception of read-read locks, of > course) and semaphores will deadlock on recursive use, while the BKL > has this "process usage counter" recursion protection. Obtaining a read lock twice can deadlock too, can't it? A B read_lock() write_lock() ...sleeps... read_lock() ...sleeps... Or do we not make new readers sleep if there's a writer waiting? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ess maestro, support for hardware volume control
> this patch applies to (at least) 2.4.3 up to and including 2.4.6-pre2. > It enables the hardware volume control feature of the maestro. it doesnt apply to the current version of the maestro driver (2.4.5-ac) however. I think it is clashing with the docking station support - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
On Sat, 9 Jun 2001, Alexander Viro wrote: > > Another difference from spinlocks is that BKL is recursive. I'm > actually surprised that it didn't show up first. Good point. Spinlocks (with the exception of read-read locks, of course) and semaphores will deadlock on recursive use, while the BKL has this "process usage counter" recursion protection. I'm not THAT suprised that it didn't show up first - I suspect we are getting close to the point where we could actually start to remove it. The big kernel lock is not used that much any more, and there aren't that many things that are recursively invoced any more. The big reason for having a recursive lock for the BKL was because things like page faults had to nest with other users of the BKL, but since the VM should be pretty much entirely BKL-free the only real remaining part is probably small parts of the low-level filesystems (notably things like "readpage()" calling down to the get_block() functions). And I suspect that the current checker doesn't realize that any user mode access is equivalent to calling "do_page_fault()" from a call-chain standpoint. Dawson - the user-mode access part is probably _the_ most interesting from a lock checking standpoint, could you check doing the page fault case? Anyway, in a 2.5.x timeframe we should probably make sure that we do not have the need for a recursive BKL any more. That shouldn't be that hard to fix, especially with help from CHECKER to verify that we didn't forget some case. (Even if we were to not need the recursiveness of the BKL, I doubt it would mean that we'd change the implementation. The "release BKL on schedule" semantic still means that we'd have to maintain one bit of "counter", and then we might as well do the full thing. But considering recursion to be a bug would probably make it easier to continue the removal of the BKL). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] security rules? (and 2.4.5-ac4 security bug)
On Mon, Jun 04, 2001 at 08:20:01AM -0400, Hank Leininger wrote:
> On 2001-06-03, Dawson Engler <[EMAIL PROTECTED]> wrote:
>
> > Additionally, do people have suggestions for good security rules?
> > We're looking to expand our security checkers. Right now we just have
> > checkers that warn when:
>
> Do you already have checks for signed/unsigned issues? Those often result
> in security problems, although you may already be checking for them simply
> for reliable-code purposes. ...Hm, looking at the archives, I see Chris
> Evans responded about signedness issues when you asked last month :-P
Indeed; the bug in the uuid_strategy which you pointed out in the
random driver wasn't caused by the fact that we were using a
user-specified length (since the length was being capped to a maximum
value of 16). The security bug was that the test was done on a signed
value, and copy_to_user() takes an unsigned value.
So your checker found a real bug, but it wasn't the one that the
checker thought it was. :-)
Alan, I assume you've fixed this already, but here's a patch in case
you haven't. Note this also fixes the problem the problem pointed out
by Florian Weimer about copy_to_user being passed a null pointer in
the RANDOM_UUID case.
- Ted
--- random.c2001/06/09 18:05:08 1.1
+++ random.c2001/06/09 18:05:19
@@ -1793,7 +1793,7 @@
void *newval, size_t newlen, void **context)
{
unsigned char tmp_uuid[16], *uuid;
- int len;
+ unsigned intlen;
if (!oldval || !oldlenp)
return 1;
@@ -1810,7 +1810,7 @@
if (len) {
if (len > 16)
len = 16;
- if (copy_to_user(oldval, table->data, len))
+ if (copy_to_user(oldval, uuid, len))
return -EFAULT;
if (put_user(len, oldlenp))
return -EFAULT;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ess maestro, support for hardware volume control
> below is the version with the suggested fixes, and with s/hwv/hwvol/ for
> hwv_input also.
fantastic, thanks lukas.
alan, can you throw this in -ac? I don't think it will cause problems
for people with nonstandard wiring on the hw vol pins (read: dell
lattitudes), but if it does we can blacklist the lattitudes (later turning
into enabling support code for their custom hw vol wiring.. its on the
todo list :/). This should work on inspirons.
- z
> --- linux-2.4.6-pre2/drivers/sound/maestro.c Sat Jun 9 16:55:22 2001
> +++ linux/drivers/sound/maestro.c Sat Jun 9 19:48:34 2001
> @@ -115,6 +115,10 @@
> * themselves, but we'll see.
> *
> * History
> + * v0.15 - Jun 09 2001 - Lukas Schroeder <[EMAIL PROTECTED]>
> + * enable hardware volume control (by default)
> + * add hwvol_enable= to allow disabling of HWV (values are 0 or 1)
> + * add hwvol_input= to allow selecting the HWV input pins (values are 0 or 1)
> * (still kind of v0.14) Nov 23 - Alan Cox <[EMAIL PROTECTED]>
> * Add clocking= for people with seriously warped hardware
> * (still v0.14) Nov 10 2000 - Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> @@ -269,8 +273,13 @@
>
> static int clocking=48000;
>
> +/* enable hardware volume control? */
> +static int hwvol_enable = 1;
> +/* hardware volume input pin selection */
> +static int hwvol_input = 0;
> +
> /* - */
> -#define DRIVER_VERSION "0.14"
> +#define DRIVER_VERSION "0.15"
>
> #ifndef PCI_VENDOR_ESS
> #define PCI_VENDOR_ESS 0x125D
> @@ -312,6 +321,9 @@
> #define NR_APUS 64
> #define NR_APU_REGS 16
>
> +/* steps per hardware volume count */
> +#define HWV_MIXER_STEP 15
> +
> /* acpi states */
> enum {
> ACPI_D0=0,
> @@ -514,6 +526,7 @@
>
> /* - */
>
> +static void set_mixer(struct ess_card *card,unsigned int mixer, unsigned int val ) ;
> static void check_suspend(struct ess_card *card);
>
> static struct ess_card *devs = NULL;
> @@ -1898,10 +1911,20 @@
>
> if(event&(1<<6))
> {
> - /* XXX if we have a hw volume control int enable
> - all the ints? doesn't make sense.. */
> + unsigned int val;
> +
> event = inw(c->iobase+0x18);
> - outb(0xFF, c->iobase+0x1A);
> + outb((1<<6), c->iobase+0x1A);
> +
> + /* read the HW Master Volume Counter
> + Bits 7:5 Master Volume Left
> + Bits 3:1 Master Volume Right
> +*/
> + i = inb(c->iobase+0x1f);
> + val = ((HWV_MIXER_STEP * ((i>>1) & 7)) << 8) | HWV_MIXER_STEP *
>((i>>5) & 7);
> + spin_lock(>lock);
> + set_mixer(c, 0, val);
> + spin_unlock(>lock);
> }
> else
> {
> @@ -3088,8 +3111,10 @@
> w&=~(1<<14);/* External clock */
>
> w&=~(1<<7); /* HWV off */
> + if (hwvol_enable) w|=(1<<7);
> w&=~(1<<6); /* Debounce off */
> - w&=~(1<<5); /* GPIO 4:5 */
> + w&=~(1<<5); /* GPIO 4:5 ; HVI pin selection */
> + if (hwvol_input) w|=(1<<5);
> w|= (1<<4); /* Disconnect from the CHI. Enabling this made a dell
>7500 work. */
> w&=~(1<<2); /* MIDI fix off (undoc) */
> w&=~(1<<1); /* reserved, always write 0 */
> @@ -3170,7 +3195,8 @@
> outw(w, iobase+0x18);
>
> w=inw(iobase+0x18);
> - w&=~(1<<6); /* Harpo off */
> + w&=~(1<<6); /* HWV irq off */
> + if (hwvol_enable) w|=(1<<6);
> outw(w, iobase+0x18);
>
> w=inw(iobase+0x18);
> @@ -3487,6 +3513,7 @@
> /* now go to sleep 'till something interesting happens */
> maestro_power(card,ACPI_D2);
>
> + printk(KERN_INFO "maestro: hardware volume control %senabled\n",
>(hwvol_enable) ? "" : "not ");
> printk(KERN_INFO "maestro: %d channels configured.\n", num);
> return 1;
> }
> @@ -3593,6 +3620,10 @@
> MODULE_PARM(dsps_order,"i");
> MODULE_PARM(use_pm,"i");
> MODULE_PARM(clocking, "i");
> +
> +MODULE_PARM(hwvol_enable, "i");
> +MODULE_PARM(hwvol_input, "i");
> +
>
> void cleanup_module(void) {
> M_printk("maestro: unloading\n");
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] usb.c: USB device not accepting new address=4 (error=-110)
On Sat, Jun 09, 2001 at 06:14:24AM -0700, David Brownell wrote: > Then whatever sets up your ServerWorks ServerSet III LE chipset > needs its PCI IRQ setup fixed ... I'm not sure how to do this. > > Perhaps someone who's familiar with arch/i386/kernel/pci-*.c > irq setup can suggest the right patch for this problem. I think > the "dmesg" output in your original post probably had the info > needed to figure that out. > > - Dave > > > > From: "Ingo Oeser" <[EMAIL PROTECTED]> > > Sent: Saturday, June 09, 2001 12:19 AM > > > > > David Brownell wrote: > > > Can you verify, using /proc/interrupts, that you're actually > > > getting interrupts on irq #30 when these timeouts happen? > > > > I get none: > > 30: 0 0 IO-APIC-level usb-ohci > > > > > One possibility: the timeout happens because the HCD > > > is not getting the interrupts it expects. That would imply > > > that the PCI IRQ setup for this device isn't quite right. > > > Such problems have been seen before. > > > > This seems to be my problem. How can I solve this? > > > > My BIOS cannot set a specific IRQ for USB like other BIOSes do. > > > > And now that you say^W it, I remember sth. like this on > > linux-kernel... I just didn't know the messages... > > A similar problem with USB on a VIA smp board was solved by Jeff Garzik, so you might want to send him some info, like dmesg lspci -vvvxxx Good luck, Jurriaan -- You have nothing to be afraid of. Well, that might not be true in the larger scheme of things, but this ordeal is over, so off you go. Toodle-oo. Fraser, Due South GNU/Linux 2.4.5-ac12 SMP/ReiserFS 2x1402 bogomips load av: 0.49 0.12 0.04 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: missing symbol do_softirq in net moduels for pre-2
On Sat, 9 Jun 2001 11:13:46 -0700, Wayne Whitney <[EMAIL PROTECTED]> wrote: >I have verified that the versioning of the do_softirq symbol above is >the source of the problems in 2.4.6-pre2 Resend, the first patch never appeared. The problem is the call to do_softirq inside an asm string where cpp cannot convert it. The correct fix is toe xpose do_softirq so cpp can convert it then map to a string and concatenate with teh asm string. But that requires ugly helper macros, a cleaner fix is: Against 2.4.6-pre2. Note: you must run make mrproper after applying this patch. Index: 6-pre2.1/kernel/ksyms.c --- 6-pre2.1/kernel/ksyms.c Sat, 09 Jun 2001 11:25:53 +1000 kaos (linux-2.4/j/46_ksyms.c 1.1.2.2.1.1.2.1.1.8.2.1.2.1 644) +++ 6-pre2.1(w)/kernel/ksyms.c Sun, 10 Jun 2001 03:36:12 +1000 kaos +(linux-2.4/j/46_ksyms.c 1.1.2.2.1.1.2.1.1.8.2.1.2.1 644) @@ -536,7 +536,7 @@ EXPORT_SYMBOL(remove_bh); EXPORT_SYMBOL(tasklet_init); EXPORT_SYMBOL(tasklet_kill); EXPORT_SYMBOL(__run_task_queue); -EXPORT_SYMBOL(do_softirq); +EXPORT_SYMBOL_NOVERS(do_softirq); EXPORT_SYMBOL(tasklet_schedule); EXPORT_SYMBOL(tasklet_hi_schedule); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux fails to do proper cleanups with free_vm86_irq()
I am using linux-2.2.19 and I have a problem with irq handling:
if some program requests an irq and doesn't free it before exit, I have to
reboot my machine in order to make this program to work again.
I mean dosemu: if it crashes, it doesn't handle irqs any more until reboot.
I can demonstrate the problem with the following example:
#include
#include
#include
#define OLD_SYS_vm86 113
#define NEW_SYS_vm86 166
static inline int vm86_plus(int function, int param)
{
int __res;
__asm__ __volatile__("int $0x80\n"
:"=a" (__res):"a" ((int)NEW_SYS_vm86), "b" (function), "c" (param));
return __res;
}
int main() {
printf("%s\n", vm86_plus(VM86_REQUEST_IRQ, (SIGIO << 8) | 11)>0?
"Success":"Fail");
return 0;
}
--
Running it first time (with root previleges) returns "Success", and next
starts will return "Fail".
I have looked in kernel's vm86.c and found a function handle_irq_zombies()
that must do a cleanup. It doesn't work however for some reasons.
I think the problem is that a function task_valid() compares pointers to
task_struct instead of comparing the actual structures.
Furthermore I have found out that I can make a cleanup manually just
doing VM86_FREE_IRQ within the program, started from the normal user,
not root! It just prooves that the check
if (vm86_irqs[irqnumber].tsk != current) return -EPERM;
is not valid.
Never mind, it is just my guesses...
So can anyone help me with this problem by explaining why linux fails to do
a cleanup and how to make it to do it?
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ess maestro, support for hardware volume control
> > By giving hwv=0 to insmod one can explicitly disable it. Setting
>
> can we have a better name like 'hwvol_enable'?
>
> > + set_mixer(c, 0, val);
>
> careful. you just used the indirect ac97 registers without holding the
> card's lock.. if another processor does a mixer ioctl while this is
> happening you'll get weird behaviour.
>
> Fix the locking (and the obscure parameter name? :)) and it looks
below is the version with the suggested fixes, and with s/hwv/hwvol/ for
hwv_input also.
regards,
lukas
--- linux-2.4.6-pre2/drivers/sound/maestro.cSat Jun 9 16:55:22 2001
+++ linux/drivers/sound/maestro.c Sat Jun 9 19:48:34 2001
@@ -115,6 +115,10 @@
* themselves, but we'll see.
*
* History
+ * v0.15 - Jun 09 2001 - Lukas Schroeder <[EMAIL PROTECTED]>
+ * enable hardware volume control (by default)
+ * add hwvol_enable= to allow disabling of HWV (values are 0 or 1)
+ * add hwvol_input= to allow selecting the HWV input pins (values are 0 or 1)
* (still kind of v0.14) Nov 23 - Alan Cox <[EMAIL PROTECTED]>
* Add clocking= for people with seriously warped hardware
* (still v0.14) Nov 10 2000 - Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
@@ -269,8 +273,13 @@
static int clocking=48000;
+/* enable hardware volume control? */
+static int hwvol_enable = 1;
+/* hardware volume input pin selection */
+static int hwvol_input = 0;
+
/* - */
-#define DRIVER_VERSION "0.14"
+#define DRIVER_VERSION "0.15"
#ifndef PCI_VENDOR_ESS
#define PCI_VENDOR_ESS 0x125D
@@ -312,6 +321,9 @@
#define NR_APUS64
#define NR_APU_REGS16
+/* steps per hardware volume count */
+#define HWV_MIXER_STEP 15
+
/* acpi states */
enum {
ACPI_D0=0,
@@ -514,6 +526,7 @@
/* - */
+static void set_mixer(struct ess_card *card,unsigned int mixer, unsigned int val ) ;
static void check_suspend(struct ess_card *card);
static struct ess_card *devs = NULL;
@@ -1898,10 +1911,20 @@
if(event&(1<<6))
{
- /* XXX if we have a hw volume control int enable
- all the ints? doesn't make sense.. */
+ unsigned int val;
+
event = inw(c->iobase+0x18);
- outb(0xFF, c->iobase+0x1A);
+ outb((1<<6), c->iobase+0x1A);
+
+ /* read the HW Master Volume Counter
+ Bits 7:5 Master Volume Left
+ Bits 3:1 Master Volume Right
+*/
+ i = inb(c->iobase+0x1f);
+ val = ((HWV_MIXER_STEP * ((i>>1) & 7)) << 8) | HWV_MIXER_STEP *
+((i>>5) & 7);
+ spin_lock(>lock);
+ set_mixer(c, 0, val);
+ spin_unlock(>lock);
}
else
{
@@ -3088,8 +3111,10 @@
w&=~(1<<14);/* External clock */
w&=~(1<<7); /* HWV off */
+ if (hwvol_enable) w|=(1<<7);
w&=~(1<<6); /* Debounce off */
- w&=~(1<<5); /* GPIO 4:5 */
+ w&=~(1<<5); /* GPIO 4:5 ; HVI pin selection */
+ if (hwvol_input) w|=(1<<5);
w|= (1<<4); /* Disconnect from the CHI. Enabling this made a dell
7500 work. */
w&=~(1<<2); /* MIDI fix off (undoc) */
w&=~(1<<1); /* reserved, always write 0 */
@@ -3170,7 +3195,8 @@
outw(w, iobase+0x18);
w=inw(iobase+0x18);
- w&=~(1<<6); /* Harpo off */
+ w&=~(1<<6); /* HWV irq off */
+ if (hwvol_enable) w|=(1<<6);
outw(w, iobase+0x18);
w=inw(iobase+0x18);
@@ -3487,6 +3513,7 @@
/* now go to sleep 'till something interesting happens */
maestro_power(card,ACPI_D2);
+ printk(KERN_INFO "maestro: hardware volume control %senabled\n",
+(hwvol_enable) ? "" : "not ");
printk(KERN_INFO "maestro: %d channels configured.\n", num);
return 1;
}
@@ -3593,6 +3620,10 @@
MODULE_PARM(dsps_order,"i");
MODULE_PARM(use_pm,"i");
MODULE_PARM(clocking, "i");
+
+MODULE_PARM(hwvol_enable, "i");
+MODULE_PARM(hwvol_input, "i");
+
void cleanup_module(void) {
M_printk("maestro: unloading\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.2.19 DMA problem
Hi there. A friend of mine is having a problem with the 2.2.19 kernel on one of his boxes, and has asked for some advice which is beyond my experience so I'm asking here: Is this a kernel problem or something else? First, the hardware, as best we can determine: Vesa VLB motherboard, model unknown. Intel 486dx4/100 stepping 0. 48 Mb of RAM eth0 is an RTL8009 chipset configured for 0x300/IRQ9 Serial port 0x3f8/4 (16550A) connects to an external modem Serial port 0x2f8/3 (16550A) is unused The boix in question isn't used for compiling, but here's what the ver_linux script from 2.2.18 produced on it: binutils: 2.9.5.0.22 util-linux: 2.10f modutils: 2.3.21 e2fsprogs: 1.18 PPP:2.3.11 Linux C Library:2.1.3 Dynamic Linker (ldd): 2.1.3 Procps: 2.0.6 Net-tools: 1.54 Console-tools: 0.3.3 Sh-utils: 2.0 The machine that compiled the kernel has: Gnu-C: egcs-2.91.66 Gnu Make: 3.77 Binutils: 2.9.1.0.24 The problem machine irregularly spams the following over both the console and syslog (taken from syslog): Q> Jun 9 17:34:04 Doorstep kernel: eth0: DMAing conflict in Q> ne_block_output.[DMAstat:1][irqlock:1][intr:0] Q> Jun 9 17:34:04 Doorstep kernel: eth0: DMAing conflict in Q> ne_get_8390_hdr.[DMAstat:1][irqlock:0][intr:1] When this happens, the spam can be stopped by `ifconfig eth0 down` but the card is totally dead and can only be restarted by rebooting the machine. Can anybody advise on likely solutions, as this is his firewall gateway machine, so causes quite a bit of inconvenience. Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NFS PANIC and FIX in 2.4
Hi All,
I get this panic running RedHat 2.4.3-6:
Unable to handle kernel NULL pointer dereference at virtual address 0004
c014b13d
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: ebx: c4a6dcc0 ecx: c4a6dce8 edx:
esi: c0256ed8 edi: c59197a0 ebp: c4ba79e8 esp: c4ba78a0
ds: 0018 es: 0018 ss: 0018
Process nfsd (pid: 3230, stackpage=c4ba7000)
Stack: c1239148 c4a6d9e8 c4a6dcc0 c4a6d9c0 c4a6dcc0 c4a6d9c0 c68af335 c4a6dcc0
c4a6d9c0 c4ba79e8 c4a6d9c0 c59197a0 c68af59a c4a6d9c0 c59197a0
c4ba79e8 00706d74 c5e07d80 c1e9ec00 c014d972 c1e9ec00 7458
Call Trace: [] [] [] [] []
[] [] [] [] [] [
]
[...]
>>EIP; c014b13d<=
Trace; c68af335 <[nfsd]d_splice+e5/160>
Trace; c68af59a <[nfsd]splice+ea/140>
Trace; c014d972
Trace; c016bf17
[...]
Code; c014b13d
<_EIP>:
Code; c014b13d<=
0: 89 50 04 mov%edx,0x4(%eax) <=
Code; c014b140
3: 89 02 mov%eax,(%edx)
Code; c014b142
5: c7 43 28 00 00 00 00 movl $0x0,0x28(%ebx)
Code; c014b149
c: c7 41 04 00 00 00 00 movl $0x0,0x4(%ecx)
Code; c014b150
13: 8b 00 mov(%eax),%eax
This is in dcache.c here:
kill_it: {
struct dentry *parent;
list_del(>d_child);
^^
/* drops the lock, at that point nobody can reach this dentry */
dentry_iput(dentry);
The problem is pretty specific to 2.4.3-6 because it has code in list_del() to
null out the prev and next pointers (I don't know where they picked it up, but
its gone in 2.4.5). However, it exposes a bug in NFS, namely that d_splice()
also calls list_del() on tdentry->d_child. This shouldn't be done because it
makes the d_child list invalid, so any subsequent call to list_del on d_child
could panic. I think the correct fix (attached below) is to change the NFS
list_del to list_del_init.
James Bottomley
Steeleye technology.
Index: linux/2.4/fs/nfsd/nfsfh.c
diff -u linux/2.4/fs/nfsd/nfsfh.c:1.1.1.8.4.1 linux/2.4/fs/nfsd/nfsfh.c:1.1.1.8.4.2
--- linux/2.4/fs/nfsd/nfsfh.c:1.1.1.8.4.1 Wed May 9 11:08:54 2001
+++ linux/2.4/fs/nfsd/nfsfh.c Fri Jun 8 16:18:33 2001
@@ -238,7 +238,7 @@
* make it an IS_ROOT instead
*/
spin_lock(_lock);
- list_del(>d_child);
+ list_del_init(>d_child);
tdentry->d_parent = tdentry;
spin_unlock(_lock);
d_rehash(target);
3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
I have tried 2.4.5-pre2 up to 2.4.6-pre1 with the same results. Everything boots great and I can login fine. When I try to assign an IP via DHCP or ifconfig, the system sits and stares at me indefinitely. 2.4.5-pre4 didn't compile for me, but pre3 works fine and pre5 locks. There is keyboard response, and Alt-SysRq will tell me that it knows I want it to sync the disks, but won't actually do it. It will reboot, though. I can switch between terminals, but cannot type anything at the login prompt. The board is a Abit KT7-RAID. I have waited to see if this issue has been resolved and will recompile the newer kernels (AC and Linus flavours) to see if it has cleared up, but wanted to see if maybe there is something else I should look at. I can provide any more information that might help, so please let me know. Thanks in advance. Glenn C. Hofmann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
On 9 Jun 2001, Linus Torvalds wrote: > The big kernel lock rules are that it's a "normal spinlock" in many > regards, BUT you can block while holding it, and the BKL will magically > be released during the blocking. This means, for example, that the BKL > can never deadlock with a semaphore - if a BKL holder blocks on sombody > elses semaphore (and that somebody else wants the BKL), then the act of > blocking on the semaphore will release the BKL, and allow the original > semaphore holder to continue. Another difference from spinlocks is that BKL is recursive. I'm actually surprised that it didn't show up first. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] truncate_inode_pages
> takes 45 seconds CPU time due to the O(clean * dirty) algorithm in
> truncate_inode_pages(). The machine is locked up for the duration.
> The patch reduces this to 20 milliseconds via an O(clean + dirty)
> algorithm.
Unfortunately, it's _not_ O(clean + dirty).
> + while (truncate_list_pages(>clean_pages, start, )) {
> + spin_lock(_lock);
> + complete = 0;
> + }
Cool. Now think what happens if pages with large indices are in the
very end of list. Half of them. You skip clean/2 pages on each of
clean/2 passes. Hardly a linear behaviour - all you need is a different
program to trigger it.
Now, having a separate pass that would reorder the pages on list,
moving the to-kill ones in the beginning might help.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
In article <[EMAIL PROTECTED]>, Dawson Engler <[EMAIL PROTECTED]> wrote: > >we're starting to develop a checker that finds deadlocks by (1) >computing all lock acquisition paths and (2) checking if two paths >violate a partial order. Looks good. >The checker is pretty primitive. In particular: > - lots of false negatives come from the fact that it does not > track interrupt disabling. A missed deadlock: > foo acquires A > bar interrupts foo, disables interrupts, tries to acquire A > (Is this the most common deadlock?) You actually find something like this at all? I would have assumed that you would never see this as a path, as interrupts aren't explicit calls. > - many potential false positives since it does not realize when > two kernel call traces are mutually exclusive. On the other hand, they should be mutually exclusive only by virtue of using some kind of locking, so this should show up in your locking order thing. The rule is - A -> B can deadlock with B -> A BUT - A -> B -> C cannot deadlock with A -> C -> B by wirtue of "A" acting as the master lock. So you should be able to see these things (arguably the "cannot deadlock" case is still a very ugly case, and also implies that B and C are irrelevant, as A already took care of exclusivity. So getting a warning for this might be fine). >To check it's mechanics I've enclosed what look to me to be two potential >deadlocks --- given the limits of the tool and my understanding of what >can happen when, these could be (likely be?) false positive, so I'd >appreciate any corrective feedback. They are, but for a very special reason: the big kernel lock is special. The big kernel lock rules are that it's a "normal spinlock" in many regards, BUT you can block while holding it, and the BKL will magically be released during the blocking. This means, for example, that the BKL can never deadlock with a semaphore - if a BKL holder blocks on sombody elses semaphore (and that somebody else wants the BKL), then the act of blocking on the semaphore will release the BKL, and allow the original semaphore holder to continue. The same is currently true of the global irq lock too (with the caveat that we don't even re-aquire it after a schedule()), but that is going to change, so I would suggest you _not_ special-case the global irq lock. But the big kernel lock is so special that I suspect it needs some special casing to avoid too many false reports. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Hi, > I haven't encountered any CPU with builtin temperature sensors. Well, I've got an Apple iMac (tee hee hee) with a PowerPC G3 (or 750 for you number guys). I know for sure that all of the G3 / G4 chips have temperature sensors built onto the CPU core. Mine's showing 23 degrees Celsius at the moment. >> This thread keeps going and going and going... > > and going, and going . and still going . and going, and going, and going... -- .-. Chris Boot /v\ [EMAIL PROTECTED] // \\ /( )\L I N U X ^^-^^>Phear the Penguin< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ess maestro, support for hardware volume control
> this patch applies to (at least) 2.4.3 up to and including 2.4.6-pre2.
> It enables the hardware volume control feature of the maestro.
cool. I had support for this in the mega-patch I posted long ago, but
I never seperated and submitted those changes 'cause I'm a moron.
> By giving hwv=0 to insmod one can explicitly disable it. Setting
can we have a better name like 'hwvol_enable'?
> + set_mixer(c, 0, val);
careful. you just used the indirect ac97 registers without holding the
card's lock.. if another processor does a mixer ioctl while this is
happening you'll get weird behaviour.
it looks like you should just be able to spin_{,un}lock(card->lock)
around that call, but the maestro locking is so friggin' twisty.. this
gets even more exciting when the driver uses ac97_codec, which the
mega-patch also had in it.
Fix the locking (and the obscure parameter name? :)) and it looks
fine.. good work.
--
zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] ess maestro, support for hardware volume control
Hi,
this patch applies to (at least) 2.4.3 up to and including 2.4.6-pre2.
It enables the hardware volume control feature of the maestro.
By giving hwv=0 to insmod one can explicitly disable it. Setting
hwv_input=1 requests the alternative HWV input pins to be used.
The maestro will generate interrupts on an input signal with bit 6 at
iobase+0x1A set. This case was already tested for, but
a) nothing was done there and
b) this event never occurred anyway b/c the irq was turned off.
Now the master volume counter is read out and the mixer's
master volume is changed accordingly.
regards,
lukas
--- linux-2.4.6-pre2/drivers/sound/maestro.cSat Jun 9 16:55:22 2001
+++ linux/drivers/sound/maestro.c Sat Jun 9 17:13:24 2001
@@ -115,6 +115,10 @@
* themselves, but we'll see.
*
* History
+ * v0.15 - Jun 09 2001 - Lukas Schroeder <[EMAIL PROTECTED]>
+ * enable hardware volume control (by default)
+ * add hwv= to allow disabling of HWV (values are 0 or 1)
+ * add hwv_input= to allow selecting the HWV input pins (values are 0 or 1)
* (still kind of v0.14) Nov 23 - Alan Cox <[EMAIL PROTECTED]>
* Add clocking= for people with seriously warped hardware
* (still v0.14) Nov 10 2000 - Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
@@ -269,8 +273,13 @@
static int clocking=48000;
+/* enable hardware volume control? */
+static int hwv = 1;
+/* hardware volume input pin selection */
+static int hwv_input = 0;
+
/* - */
-#define DRIVER_VERSION "0.14"
+#define DRIVER_VERSION "0.15"
#ifndef PCI_VENDOR_ESS
#define PCI_VENDOR_ESS 0x125D
@@ -312,6 +321,9 @@
#define NR_APUS64
#define NR_APU_REGS16
+/* steps per hardware volume count */
+#define HWV_MIXER_STEP 15
+
/* acpi states */
enum {
ACPI_D0=0,
@@ -514,6 +526,7 @@
/* - */
+static void set_mixer(struct ess_card *card,unsigned int mixer, unsigned int val ) ;
static void check_suspend(struct ess_card *card);
static struct ess_card *devs = NULL;
@@ -1898,10 +1911,18 @@
if(event&(1<<6))
{
- /* XXX if we have a hw volume control int enable
- all the ints? doesn't make sense.. */
+ unsigned int val;
+
event = inw(c->iobase+0x18);
- outb(0xFF, c->iobase+0x1A);
+ outb((1<<6), c->iobase+0x1A);
+
+ /* read the HW Master Volume Counter
+ Bits 7:5 Master Volume Left
+ Bits 3:1 Master Volume Right
+*/
+ i = inb(c->iobase+0x1f);
+ val = ((HWV_MIXER_STEP * ((i>>1) & 7)) << 8) | HWV_MIXER_STEP *
+((i>>5) & 7);
+ set_mixer(c, 0, val);
}
else
{
@@ -3088,8 +3109,10 @@
w&=~(1<<14);/* External clock */
w&=~(1<<7); /* HWV off */
+ if (hwv) w|=(1<<7);
w&=~(1<<6); /* Debounce off */
- w&=~(1<<5); /* GPIO 4:5 */
+ w&=~(1<<5); /* GPIO 4:5 ; HVI pin selection */
+ if (hwv_input) w|=(1<<5);
w|= (1<<4); /* Disconnect from the CHI. Enabling this made a dell
7500 work. */
w&=~(1<<2); /* MIDI fix off (undoc) */
w&=~(1<<1); /* reserved, always write 0 */
@@ -3170,7 +3193,8 @@
outw(w, iobase+0x18);
w=inw(iobase+0x18);
- w&=~(1<<6); /* Harpo off */
+ w&=~(1<<6); /* HWV irq off */
+ if (hwv) w|=(1<<6);
outw(w, iobase+0x18);
w=inw(iobase+0x18);
@@ -3487,6 +3511,7 @@
/* now go to sleep 'till something interesting happens */
maestro_power(card,ACPI_D2);
+ printk(KERN_INFO "maestro: hardware volume control %senabled\n", (hwv) ? "" :
+"not ");
printk(KERN_INFO "maestro: %d channels configured.\n", num);
return 1;
}
@@ -3593,6 +3618,10 @@
MODULE_PARM(dsps_order,"i");
MODULE_PARM(use_pm,"i");
MODULE_PARM(clocking, "i");
+
+MODULE_PARM(hwv, "i");
+MODULE_PARM(hwv_input, "i");
+
void cleanup_module(void) {
M_printk("maestro: unloading\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Ext3 kernel RPMS (2.4.5 & 2.2.19)
"P.A.M. van Dam" wrote: > > On Fri, Jun 08, 2001 at 03:23:16PM -0600, Peter J. Braam wrote: > > Hi, > > > > Mostly for my own use, I prepared two kernel RPM's with Ext3 in them. > > > > Versions: > > 2.2.19 + 0.0.7a > > 2.4.5 + 0.0.6 > > > > PLEASE USE THESE AT YOUR OWN RISK - THEY CONTAIN EXPERIMENTAL FILE SYSTEM > > CODE. > > - Peter J. Braam - > > http://www.clusterfilesystem.com > > Ext3 for 2.4 kernels. Great. It's probably been asked before, but where can I > find the ext3 patch for the 2.4 kernels? All the details are at http://www.uow.edu.au/~andrewm/linux/ext3/ Current status is "pretty solid". Performance is good. It's basically untested against LVM and RAID. It can deadlock under heavy load if you're using quotas. Avoid those things and you shouldn't have any problems. Porting it (back) over to -ac and fixing up the quota problems is basically the next activity on 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: Ext3 kernel RPMS (2.4.5 & 2.2.19)
On Fri, Jun 08, 2001 at 03:23:16PM -0600, Peter J. Braam wrote: > Hi, > > Mostly for my own use, I prepared two kernel RPM's with Ext3 in them. > > Versions: > 2.2.19 + 0.0.7a > 2.4.5 + 0.0.6 > > PLEASE USE THESE AT YOUR OWN RISK - THEY CONTAIN EXPERIMENTAL FILE SYSTEM > CODE. > - Peter J. Braam - > http://www.clusterfilesystem.com Ext3 for 2.4 kernels. Great. It's probably been asked before, but where can I find the ext3 patch for the 2.4 kernels? Thanks in advance! Best regards, Pascal > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message 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: Probable endianess problem in TLAN driver
"Mathiasen, Torben" wrote: > > Paulo, > > Thanks for the update/patch. Sorry I missed your first email, bu I've been > way too busy with other stuff the last couple of months. Thank Hollis. :-) As I've already said, I'm really no kernel hacker. OTOH I've programmed a lot 5+ years ago, so I can understand some things. I'm relieved also that you have replied, because seemed that you had a disease or something - your contributions both to the list and updates to the page stopped abruptly. > There's a lot of endianess issues in the tlan driver, but none really > bothered fixing them. No one really assumed the tlan adapters would be used > on bigendian machines. Well, let me say, you're probaly the first ;-). Actually, I decided on Netelligent Dual because of two things: * I had the oportunity to get such a board by a reasonable price (US$ 50.00); here in Brazil, it's rather difficult to get real multiport adapters (what is available are hubs-on-a-board. Bleargh). The ones available are Adaptec ones, and here they cost US$ 500.00 up. Too bad because they have the 21x4x chip that works flawlessly on PPC. :-( * I've read someplace that someone got to make TLAN work on PowerPC (no links, please :-). He said also that MacOS would olympically ignore the driver, but it would work on PPCLinux. Even in US multiport Adaptec boards are not cheap; in eBay prices vary from US$ 150 to US$ 225. > Now, I have pile of updates/issues for the tlan driver I need to check up > on. Hopefully I'll have some sparetime within a reasonable future to address > this. The adapter ROM must be enabled for the driver work? I'm asking this because lspci -v shows that the adapter ROM in both ports is "disabled". > BTW. The project page on compaq.com is the "new" tlan site. Could you the group membership issues on the site? I'd like to see the bug reports but I can't do it. Check the site for the actual messages without logging in. > Thanks, > > Torben Mathiasen Thanks also! Paulo -- Now I want you to remember that no bastard ever won a war by dying for his country. He won it by making the other poor dumb bastard die for his country. (Gen. George S. Patton Jr.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: missing symbol do_softirq in net moduels for pre-2
On Sat, 9 Jun 2001 11:07:52 -0400, Ed Tomlinson <[EMAIL PROTECTED]> wrote: >Built -pre2 and noticed most of the modules in net/* are getting >a missing symbol for do_softirq. http://www.tux.org/lkml/#s8-8 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OPL3-SA2 driver and Intel AL400LX onboard sound problems
Hi, Just updated to 2.4.5 from 2.2.18 and there seems to be a difference in the OPL3-SA2 sound driver. I have an Intel AL440LX motherboard with onboard sound, after setting up the sound driver under 2.4.5 I get a strange effect when trying to play any sound files; the files play very slow (like the sample rate is off), the volume is very low (the mixer seems to take no effect) and there is lots of interference (hissing). I only get hissing from the left speaker and the much too slow, very bassy, distorted sound from the right speaker. This happens when I try to play MP3s from xmms and when I cat a wav straight to /dev/snd. I've tried setting the card up with isapnp and the kernel ISA PNP features, both have the same effect. Using isapnp under 2.2.18 my sound worked perfectly. I am currently using the kernel ISA PNP features. When the kernel loads I get: Jun 9 16:39:22 yoshi kernel: isapnp: Scanning for PnP cards... Jun 9 16:39:22 yoshi kernel: isapnp: Card 'OPL3-SA3 Snd System' Jun 9 16:39:22 yoshi kernel: isapnp: 1 Plug & Play card detected total When sound is initialised I get: Jun 9 16:39:34 yoshi kernel: opl3sa2: Found OPL3-SA3 (YMF715 or YMF719) Jun 9 16:39:34 yoshi kernel: at 0x100 Jun 9 16:39:34 yoshi kernel: at 0xe84 irq 5 dma 1,3 Jun 9 16:39:35 yoshi kernel: at 0x300 irq 5 Jun 9 16:39:35 yoshi kernel: opl3sa2: 1 PnP card(s) found. /proc/interrupts looks like: 5: 14783 XT-PIC MS Sound System (rest omitted) The values in /proc/isapnp appear to match as well (I won't dump that all here though) as do the values in /proc/ioports (I will leave that out too unless requested later). I am fairly sure there is no conflict there. I had heard murmers that this driver had been through some changes and looking through the list archives has shown that there have been some problems in 2.4.x with this driver before; nothing seems to match my problem though. Could anyone point me in the direction of trying to solve this problem? It doesn't have to be a patch, I'm fairly good at looking through source, its just that I haven't got a clue where to start. Any tips would be appreciated. Of course, if a fix already exists please point me at it instead of going through it the hard way...! Thanks in advance. Robin -- E-Mail: [EMAIL PROTECTED] WWW: http://www.phaderunner.demon.co.uk/ GnuPG public key: http://www.phaderunner.demon.co.uk/Robin_Cull.key.asc "It's easier to ask forgiveness than it is to get permission." -- Rear Admiral Dr. Grace Hopper (sponsor of COBOL...) PGP signature
[patch] truncate_inode_pages
The ftruncate() in this program:
#include
#include
#include
int clean = 64 * 1024 * 1024;
int dirty = 64 * 1024 * 1024;
main()
{
int fd = open("foo", O_RDWR|O_TRUNC|O_CREAT, 0666);
void *mem;
ftruncate(fd, clean + dirty);
mem = mmap(0, clean + dirty, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
memset(mem, 0, clean + dirty);
msync(mem, clean, MS_SYNC);
ftruncate(fd, clean);
}
takes 45 seconds CPU time due to the O(clean * dirty) algorithm in
truncate_inode_pages(). The machine is locked up for the duration.
The patch reduces this to 20 milliseconds via an O(clean + dirty)
algorithm.
--- linux-2.4.5/mm/filemap.cMon May 28 13:31:49 2001
+++ linux-akpm/mm/filemap.c Sun Jun 10 01:27:09 2001
@@ -273,15 +273,24 @@
{
unsigned long start = (lstart + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
unsigned partial = lstart & (PAGE_CACHE_SIZE - 1);
+ int complete;
-repeat:
spin_lock(_lock);
- if (truncate_list_pages(>clean_pages, start, ))
- goto repeat;
- if (truncate_list_pages(>dirty_pages, start, ))
- goto repeat;
- if (truncate_list_pages(>locked_pages, start, ))
- goto repeat;
+ do {
+ complete = 1;
+ while (truncate_list_pages(>clean_pages, start, )) {
+ spin_lock(_lock);
+ complete = 0;
+ }
+ while (truncate_list_pages(>dirty_pages, start, )) {
+ spin_lock(_lock);
+ complete = 0;
+ }
+ while (truncate_list_pages(>locked_pages, start, )) {
+ spin_lock(_lock);
+ complete = 0;
+ }
+ } while (!complete);
spin_unlock(_lock);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
missing symbol do_softirq in net moduels for pre-2
Hi, Built -pre2 and noticed most of the modules in net/* are getting a missing symbol for do_softirq. Have I messed up, or is there a real error? Ed Tomlinson <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
James Sutherland <[EMAIL PROTECTED]> wrote: > > The current x86 setup uses a small sensor sitting under the CPU socket. Current Intel chips have a sensor built right into the die of the processor itself -- voila, close enough to the critical junction temperature for any purpose. Many workstation CPUs have a similar feature, and the other x86 manufacturers either do or have plans to include such a beast. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IRQ problems on new Toshiba Libretto
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there! I am trying to install Linux 2.4.4 on the new Toshiba Libretto, the one with the Crusoe CPU, 1280x600 screen, 1kg (I think it is currently only sold in Japan). I am having problems with IRQs and the recognition of system components, which I suspect is the reason, why about half of my devices are unusable. I am getting the message "PCI: No IRQ known for interrupt pin A of device 00:00.0. Please try using pci=biosirq." This message is repeated for the following devices: 00:00.0 Host bridge: Transmeta Corporation LongRun Northbridge 00:06.0 Multimedia audio controller: Acer Laboratories Inc. 00:0f.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 00:10.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c3) 00:12.0 CardBus bridge: Toshiba ToPIC95 PCI to Cardbus Bridge 01:00.0 Ethernet controller: DECchip 21142/43 I have put the details of /var/log/messages, lspci, /proc/pci, pnpdump and the kernel configuration into the file http://launchers.tripod.com/linux/libretto_logs_n_kernelconfig.txt I searched the mailing-list archives for this error message for the last days, applying suggested kernel parameters and kernel-patches, but without success. Unfortunately the Libretto seems to have no common BIOS - didn't find how to enter and change anything - - all settings are done from Windows :-( Now I have a number of problems, which I suspect are a consequence of the above error message: o PCMCIA cards are not initialized and return the above error message (for device 01:00.0) when inserted. Therefore I can currently not use any PCMCIA device (modem, ethernet, CD-Rom !!!) - THIS IS CRITICAL! o ACPI output is bogus, showing a remaining battery capacity, which jumps every few seconds to levels somewhere between 0 and 100%. The Librtto only supports ACPI. I am using version acpi-20010518 patched against kernel 2.4.4, so it should be up-to-date. o I can not find my internal (win)modem. Neither lspci -vvv, pnpdump nor /proc/pci give any evidence - - but the modem works fine under windows - I mean it is really there. o I fail to initialize the ASLA-sound module for my ALi-chip (same error message). At the moment the core system (CPU, memory, harddisk, screen and keyboard) is working well. But I would like to make the whole system work properly - just don't know what else I can do. I'm not a kernel hacker. Can anybody help? THANKS! Aron PS: Because I am not subscribed to the mailing-list, could you please CC any comments to me directly. ___ A r o nL E N T S C H N A L - National Aerospace Laboratory 7-44-1 Jindaiji-Higashi Chofu Tokyo 182-8522JAPAN phone +81-422-40-3173(fax ..-3138) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.3 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE7IjplTHIdV6Tf0iQRAvwCAJ92Es7Ut0MVewlbtwCA/N9uD8EuHgCgvNyU 0z1NKdZOrFEKGxn2VGdnma0= =4yKd -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac12
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac12 o Report apic timer vector in hex too (Philip Pokorny) | With 0x in front so we can tell on reports.. o Report card services differently if kernel (Jeff Garzik) o Don't terminate init on sysrq (Adam Slattery) unless forced o Add more pci wrappers when PCI is off (Jeff Garzik) o Remove 4K object from the stack in emu10k1 (me) o Remove 3.5K object from the i2o_proc stack (me) o Remove 3K object from the ewrk3 ioctl stack (me) o Fix bugs in the es1371 locking (me) o Fix ohci iso alignments (Roman Weissgaerber) o Updated megaraid driver (Atul Mukker) | In paticular this now uses the new PCI api 2.4.5-ac11 o Fix the megaraid driver ioctl check (me) o Fix the moxa ioctl checks (me) o Fix the i810 dri length check (me) o Fix array check in se401.c (me) o Fix scc irq array problems (me) o Fix sign check on zr36120 (me) o Fix sign check in raw driver(me) o Fix zr36067 array size check(me) | All the above from the Stanford checker o Fix an irq order assumption in the i810 audio (Doug Ledford) o Make real mode poweroff configurable and also (Arjan van de Ven) add DMI entries for it o Clean up Alpha oops reporting (Will Woods) o Fix ia64 build bug from mmap change (Bill Nottingham) o Fix sysinfo padding so m68k comes out right (Jes Sorensen) o Update pci ids related to ide devices (Andre Hedrick) o Update ide registers/ioctl numbers/info (Andre Hedrick) o Fix speed detection on slc90e66 (Andre Hedrick) o Update promise IDE driver (Andre Hedrick) o osb4 becomes generic serverworks ide driver (Andre Hedrick) o Use new inits on ide_tape, add a reinit (Andre Hedrick) o Use new inits on ide_floppy add a reinit(Andre Hedrick) o Add amd74xx ide driver (Andre Hedrick) o Tidy up ide disk init/reinit. Add feature (Andre Hedrick) register clear o Additional ide updates (Andre Hedrick) 2.4.5-ac10 o Fix xircom cardbus filter setup (Ion Badulescu) o Dave Jones has moved(Dave Jones) o Further Configure.help cleanup (Eric Raymond) o Switch usb serial driver locking(Greg Kroah-Hartmann) o Update IRDA Irnet protocol code (Jean Tourrilhes) o Update ide-tape and osst drivers(Willem Riede) o Add ethtool support to ne2k-pci (Jeff Garzik) o Misc small network driver tweaks/cleanup(Jeff Garzik) o Module description strings for net drivers (Jeff Garzik) o Fix thread/unload race in reiserfs (Nikita Danilov) o Fix a race in reiserfs_writepage(Chris Mason) o Add prolific 2203 USB serial support(Greg Kroah-Hartmann) o Update isdn maintainers (Kai Germaschewski) o Add another USS720 device entry (Steve Tell) o Reap dead swap cache pages (Marcelo Tosatti) o Fix USB sign handling error (Jochen Pernsteiner) o Update input driver docs(Vojtech Pavlik) o Fix locking bug in hysdn(Kai Germaschewski) o Fix hid parsing bug with feature reports(Vojtech Pavlik) o Fix ataraid config.in bug (Jim Wright) 2.4.5-ac9 o Fix gameport link problems (Vojtech Pavlik) o Fix an oops in the sg driver(Tachino Nobuhiro) o Fix brlock indexing bug (Takanori Kawano) o Add parport_pc_unregister_port (Tim Waugh) o Configure.help updates (Eric Raymond) o Fix xircom_cb problems with some cisco kit (Ion Badulescu) o Fix tdfxfb cursor rendering bug (Franz Melchior) o Add driver for the sony vaio i/o controller (Stelian Pop,
Re: VM Report was:Re: Break 2.4 VM in five easy steps
Mike Galbraith <[EMAIL PROTECTED]> writes: > On Fri, 8 Jun 2001, John Stoffel wrote: > > > Mike> OK, riddle me this. If this test is a crummy test, just how is > > Mike> it that I was able to warn Rik in advance that when 2.4.5 was > > Mike> released, he should expect complaints? How did I _know_ that? > > Mike> The answer is that I fiddle with Rik's code a lot, and I test > > Mike> with this test because it tells me a lot. It may not tell you > > Mike> anything, but it does me. > > > > I never said it was a crummy test, please do not read more into my > > words than was written. What I was trying to get across is that just > > one test (such as a compile of the kernel) isn't perfect at showing > > where the problems are with the VM sub-system. > > Hmm... > > Tobias> Could you please explain what is good about this test? I > Tobias> understand that it will stress the VM, but will it do so in a > Tobias> realistic and relevant way? > > I agree, this isn't really a good test case. I'd rather see what > > happens when you fire up a gimp session to edit an image which is > *almost* the size of RAM, or even just 50% the size of ram. Then how > does that affect your other processes that are running at the same > time? > > ...but anyway, yes it just one test from any number of possibles. One great test that I'm using regularly to see what's goin' on, is at http://lxr.linux.no/. It is a cool utility to cross reference your Linux kernel source tree, and in the mean time eat gobs of memory, do lots of I/O, and burn many CPU cycles (all at the same time). Ideal test, if you ask me and if anybody has the time, it would be nice to see different timing numbers when run on different kernels. Just make sure you run it on the same kernel tree to make reproducable results. It has three passes, and the third one is the most interesting one (use vmstat 1 to see why). When run with 64MB RAM configuration, it would swap heavily, with 128MB somewhat, and at 192MB maybe not (depending on the other applications running at the same time). Try it, it is a nice utility, and a great test. :) -- Zlatko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PANIC] aic7xxx loaded from initrd under 2.4.5
>A panic occurs at boot while the aic7xxx is doing its thing..the >following has been hand copied from the screen... Unfortunately, this trace is somewhat useless. Without symbol references, it is impossible to say where the panic occurred or where (symbol location is highly dependent on how and what you compiled (into) your kenrel. If the panic is completely reproduceable, the easiest way to get a useful dump is to apply the SGI kdb patches and get a real trace. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.2.19 rpc_execute panic (OK with 2.2.17)
On Sat, Jun 09, 2001 at 02:06:45PM +0200, Trond Myklebust wrote: > > " " == Ian Lynagh <[EMAIL PROTECTED]> writes: > > > When trying to mount something over NFS with a 2.2.19 kernel we > > get: > > > Unsupported unaligned load/store trap for kernel at > > <004d260c> Kernel panic: Wheee. Kernel does fpu/atomic > > unaligned load/store. > > Does the following patch help? Alan Cox said it is fixed in the 2.2.20pre kernels, so I will given one of them a shot. Apparently it doesn't qualify for an errata note though :-( Thanks for your quick response Ian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.2.19 rpc_execute panic (OK with 2.2.17)
> " " == Ian Lynagh <[EMAIL PROTECTED]> writes: > Hi all > We have a sun ultra 1 with /proc/cpuinfo as follows: > cpu : TI UltraSparc I (SpitFire) fpu : UltraSparc I integrated > FPU promlib : Version 3 Revision 1 prom : 3.1.1 type : sun4u > ncpus probed : 1 ncpus active : 1 BogoMips : 333.41 MMU Type : > Spitfire > When trying to mount something over NFS with a 2.2.19 kernel we > get: > Unsupported unaligned load/store trap for kernel at > <004d260c> Kernel panic: Wheee. Kernel does fpu/atomic > unaligned load/store. > Which appears to be in rpc_execute according to System.map: Does the following patch help? Cheers, Trond --- linux-2.2.19/include/linux/sunrpc/sched.h.orig Mon Mar 26 17:11:28 2001 +++ linux-2.2.19/include/linux/sunrpc/sched.h Sat Jun 9 14:04:08 2001 @@ -81,7 +81,7 @@ unsigned inttk_lock;/* Task lock counter */ unsigned char tk_active : 1,/* Task has been activated */ tk_wakeup : 1;/* Task waiting to wake up */ - unsigned inttk_runstate;/* Task run status */ + unsigned long tk_runstate;/* Task run status */ #ifdef RPC_DEBUG unsigned inttk_pid; /* debugging aid */ #endif --- linux-2.2.19/include/linux/sunrpc/xprt.h.orig Mon Mar 26 17:11:45 2001 +++ linux-2.2.19/include/linux/sunrpc/xprt.hSat Jun 9 14:04:46 2001 @@ -143,7 +143,7 @@ struct rpc_wait_queue pingwait; /* waiting on ping() */ struct rpc_rqst * free; /* free slots */ struct rpc_rqst slot[RPC_MAXREQS]; - unsigned intsockstate; /* Socket state */ + unsigned long sockstate; /* Socket state */ unsigned char nocong : 1,/* no congestion control */ stream : 1,/* TCP */ shutdown: 1,/* being shut down */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8
On Sat, 9 Jun 2001, Dawson Engler wrote: > Hi All, > > we're starting to develop a checker that finds deadlocks by (1) > computing all lock acquisition paths and (2) checking if two paths > violate a partial order. > > E.g., for two threads T1 and T2: > T1: foo acquires A --> calls bar which tries to acquire B > T2: baz acquires B --> calls blah which tries to acquire A > all else being equal, this deadlocks. > > The checker is pretty primitive. In particular: > - lots of false negatives come from the fact that it does not > track interrupt disabling. A missed deadlock: > foo acquires A > bar interrupts foo, disables interrupts, tries to acquire A > (Is this the most common deadlock?) > > - many potential false positives since it does not realize when > two kernel call traces are mutually exclusive. > > To check it's mechanics I've enclosed what look to me to be two potential > deadlocks --- given the limits of the tool and my understanding of what > can happen when, these could be (likely be?) false positive, so I'd > appreciate any corrective feedback. BKL is special. It has no nesting constraints wrt. semaphores. It is a spinlock, but we are allowed to block while holding it - then it will be released and the next time we get a timeslice we will start with attempt to reacquire it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.2.19 rpc_execute panic (OK with 2.2.17)
Hi all We have a sun ultra 1 with /proc/cpuinfo as follows: cpu : TI UltraSparc I (SpitFire) fpu : UltraSparc I integrated FPU promlib : Version 3 Revision 1 prom: 3.1.1 type: sun4u ncpus probed: 1 ncpus active: 1 BogoMips: 333.41 MMU Type: Spitfire When trying to mount something over NFS with a 2.2.19 kernel we get: Unsupported unaligned load/store trap for kernel at <004d260c> Kernel panic: Wheee. Kernel does fpu/atomic unaligned load/store. Which appears to be in rpc_execute according to System.map: 004d1dc0 T rpc_unlock_task 004d21e0 T rpc_delay 004d2220 t rpc_atrun 004d2240 t __rpc_execute 004d25a0 T rpc_execute 004d2640 t __rpc_schedule 004d27c0 T rpc_allocate 004d28e0 T rpc_free I have also compiled a 2.2.17 kernel in the same way and that works fine. We are using the RedHat sparc mount-2.10r-0.6.x RPM. I said no to the NFS 3 questions when making oldconfig from a 2.2.17 (working) config. I've attached a diff of the 2 configs. I've searched the archives but didn't seem to find anything relating to this. Can anyone suggest a fix? If you need more information to diagnose the problem please just ask. I would appreciate it if you were to CC me responses as I am not on the list. Thanks in advance Ian --- linux-2.2.19-spiffy-simple/.config Fri Jun 8 22:22:54 2001 +++ linux-2.2.17-spiffy-simple/.config Fri Jun 8 23:00:34 2001 @@ -20,18 +20,6 @@ CONFIG_VT=y CONFIG_VT_CONSOLE=y # CONFIG_SMP is not set -CONFIG_SPARC64=y -CONFIG_SBUS=y -CONFIG_SBUSCHAR=y -CONFIG_SUN_MOUSE=y -CONFIG_SERIAL=y -CONFIG_SUN_SERIAL=y -CONFIG_SERIAL_CONSOLE=y -CONFIG_SUN_KEYBOARD=y -CONFIG_SUN_CONSOLE=y -CONFIG_SUN_AUXIO=y -CONFIG_SUN_IO=y -# CONFIG_PCI is not set # # Console drivers @@ -50,6 +38,17 @@ CONFIG_FBCON_FONTWIDTH8_ONLY=y CONFIG_FONT_SUN8x16=y # CONFIG_FBCON_FONTS is not set +CONFIG_SBUS=y +CONFIG_SBUSCHAR=y +CONFIG_SUN_MOUSE=y +CONFIG_SERIAL=y +CONFIG_SUN_SERIAL=y +CONFIG_SERIAL_CONSOLE=y +CONFIG_SUN_KEYBOARD=y +CONFIG_SUN_CONSOLE=y +CONFIG_SUN_AUXIO=y +CONFIG_SUN_IO=y +# CONFIG_PCI is not set # # Misc Linux/SPARC drivers @@ -65,7 +64,9 @@ # Linux/SPARC audio subsystem (EXPERIMENTAL) # # CONFIG_SPARCAUDIO is not set +# CONFIG_SPARCAUDIO_AMD7930 is not set # CONFIG_SPARCAUDIO_CS4231 is not set +# CONFIG_SPARCAUDIO_DBRI is not set # CONFIG_SPARCAUDIO_DUMMY is not set CONFIG_SUN_OPENPROMFS=m CONFIG_NET=y @@ -130,7 +131,6 @@ # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_BRIDGE is not set -# CONFIG_NET_DIVERT is not set # CONFIG_LLC is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set @@ -200,7 +200,6 @@ CONFIG_SUNBMAC=m # CONFIG_SUNQE is not set # CONFIG_MYRI_SBUS is not set -# CONFIG_FDDI is not set # # Unix 98 PTY support @@ -214,12 +213,6 @@ # CONFIG_VIDEO_DEV is not set # -# XFree86 DRI support -# -# CONFIG_DRM is not set -# CONFIG_DRM_FFB is not set - -# # Filesystems # # CONFIG_QUOTA is not set @@ -251,14 +244,11 @@ # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=y -# CONFIG_NFS_V3 is not set CONFIG_NFSD=m -# CONFIG_NFSD_V3 is not set -# CONFIG_NFSD_TCP is not set +# CONFIG_NFSD_SUN is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_SMB_FS=m -# CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # @@ -266,7 +256,6 @@ # CONFIG_BSD_DISKLABEL=y # CONFIG_MAC_PARTITION is not set -# CONFIG_MINIX_SUBPARTITION is not set CONFIG_SMD_DISKLABEL=y CONFIG_SOLARIS_X86_PARTITION=y # CONFIG_UNIXWARE_DISKLABEL is not set @@ -308,7 +297,6 @@ # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set -# CONFIG_NLS_KOI8_RU is not set # # Watchdog
Re: Probable endianess problem in TLAN driver
Paulo Afonso Graner Fessel wrote: > [...] > He said me that these funtions don't address the endianess question, and > sent me a patch. He said that this probably wouldn't work, but I've > decided to give a try anyway. Here is the patch: > > --- tlan.c.old Thu Jun 7 21:24:25 2001 > +++ tlan.c Thu Jun 7 21:37:42 2001 > @@ -172,6 +172,12 @@ > #include > #include > > +#if defined(__powerpc__) > +#define inw(addr) le32_to_cpu(inw(addr)) > +#define inl(addr) le32_to_cpu(inl(addr)) > +#define outw(val, addr)outw(cpu_to_le32(val), addr) > +#define outl(val, addr)outl(cpu_to_le32(val), addr) > +#endif On ppc the inw, inl, outw, and outl functions already byteswap, so by adding the extra byteswap you're now passing unswapped data to the chip. Take a look at include/asm-ppc/io.h and you'll see it uses byte reversed load and store instructions. Which means that either the chip is running in a big-endian mode, or that the problem is actually with data structures placed in host memory. Often when porting a driver from i386 to ppc all that is required is to add the cpu_to_le32() macros around data in host memory that the device accesses, and to remove any #ifdef __powerpc__ code written by people who don't realise that ppc uses the standard linux pci code. -- Adrian Cox http://www.humboldt.co.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
"L. K." wrote: > I haven't encountered any CPU with builtin temperature sensors. > Eh, all Pentium class cpus have a build in sensor for core temperature (I believe Athlons too). It's just the logic which is outside in form of a A/D converter connected to a I2C bus. Regards, -- Steffen Persvold Systems Engineer Email : mailto:[EMAIL PROTECTED] Scali AS (http://www.scali.com) Tlf : (+47) 22 62 89 50 Olaf Helsets vei 6 Fax : (+47) 22 62 89 51 N-0621 Oslo, Norway - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Fri, Jun 08, 2001 at 06:08:46PM +0200, Maciej W. Rozycki wrote:
> Still it has two loops...
Ok, here is a single loop version.
Ivan.
--- 2.4.5-ac11/mm/mmap.cFri Jun 8 15:59:35 2001
+++ linux/mm/mmap.c Sat Jun 9 12:50:05 2001
@@ -398,27 +398,37 @@ free_vma:
static inline unsigned long arch_get_unmapped_area(struct file *filp, unsigned long
addr, unsigned long len, unsigned long pgoff, unsigned long flags)
{
struct vm_area_struct *vma;
+ unsigned long addr_limit = TASK_SIZE - len;
+ unsigned long addr1 = 0;
if (len > TASK_SIZE)
return -ENOMEM;
if (addr) {
addr = PAGE_ALIGN(addr);
- vma = find_vma(current->mm, addr);
- if (TASK_SIZE - len >= addr &&
- (!vma || addr + len <= vma->vm_start))
- return addr;
+ if (addr > TASK_UNMAPPED_BASE)
+ addr1 = addr;
+ goto find_free_area;
}
+
+default_area:
addr = PAGE_ALIGN(TASK_UNMAPPED_BASE);
+find_free_area:
for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
/* At this point: (!vma || addr < vma->vm_end). */
- if (TASK_SIZE - len < addr)
- return -ENOMEM;
+ if (addr_limit < addr)
+ break;
if (!vma || addr + len <= vma->vm_start)
return addr;
addr = vma->vm_end;
}
+ if (addr1) {
+ /* No unmapped areas above addr; try below it */
+ addr_limit = addr1;
+ goto default_area;
+ }
+ return -ENOMEM;
}
#else
extern unsigned long arch_get_unmapped_area(struct file *, unsigned long, unsigned
long, unsigned long, unsigned long);
--- 2.4.5-ac11/include/linux/binfmts.h Mon Jun 4 14:19:00 2001
+++ linux/include/linux/binfmts.h Mon Jun 4 20:24:50 2001
@@ -32,6 +32,9 @@ struct linux_binprm{
unsigned long loader, exec;
};
+/* Forward declaration */
+struct mm_struct;
+
/*
* This structure defines the functions that are used to load the binary formats that
* linux accepts.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On 8 Jun 2001, Bill Pringlemeir wrote: > > > "MHW" == Michael H Warfield <[EMAIL PROTECTED]> writes: > [snip] > MHW> Yes, bits are free, sort of... That's why an extra decimal > MHW> place is "ok". Keeping precision within an order of magnitude > MHW> of accuracy is within the realm of reasonable. Running out to > MHW> two decimal places for this particular application is just > MHW> silly. If it were for calibrated lab equipment, fine. But not > MHW> for CPU temperatures. > > You do introduce some rounding errors if the measurement isn't in > Celsius or Kelvin. Ie, you must do a conversion because the hardware > isn't in the desired units. In this case, the extra precision will be > beneficial. > Take for examples the motherboards with temperature sensors on them. At some point it will display the temperature of the motherboard. This rises questions: The motherboard will not have the same temeprature in two distinct points. The temperature will be highere where there are presne some thermistors or transistors that need cooloing and have a heatsink on top of them. So, where are the sensors on the motherboard put ? I don't think that there are a lot of them and then to display the average temperature. This would be a stupid thing to do. You want to know the temperature of the motherboard for different resons. If you have a case that it is sealed by the manufacturer and cannot keep it open to allow the components to cooldown when things get hot inside or outside (in the summer), you will have to rely on the motherboard sensors. And if it happens to have in your computer some graphics card that generates a lot of heat (like a Voodoo 2, or GeForce without a cooler), a TV tunner, some of the heat generated will be passed on to the motherboard. And some motherboard manufacturers insert beetween PCI/ISA slots different componenents that can be affected by the heat generated by the cards in the slots. And your confidence in the sensors in the motherboard disapperas. The only thing you can trust nowadays is the one that messures the temperature of the CPU (not very accurate). We can talk about accuracy of temperature measurment when the sensors inside our computer get as good as those used in a laboratory. Untill then ... > If you are going your route, you should send error bars with all the > measurements ;-) Fine, too many decimals leads to a false sense of > security. However, no one knows the accuracy of any future > temperature sensors so why not accommodate the possibility. Certainly > some band gap semis can give a pretty good measurement if you have > good coupling. If the temperature sensor was built into the CPU, you > might actually have accuracy! > I haven't encountered any CPU with builtin temperature sensors. > regards, > Bill Pringlemeir. > > This thread keeps going and going and going... and going, and going . and still going . > > and still going . Regards, /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: Probable endianess problem in TLAN driver
Paulo, Thanks for the update/patch. Sorry I missed your first email, bu I've been way too busy with other stuff the last couple of months. There's a lot of endianess issues in the tlan driver, but none really bothered fixing them. No one really assumed the tlan adapters would be used on bigendian machines. Well, let me say, you're probaly the first ;-). Now, I have pile of updates/issues for the tlan driver I need to check up on. Hopefully I'll have some sparetime within a reasonable future to address this. BTW. The project page on compaq.com is the "new" tlan site. Thanks, Torben Mathiasen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: temperature standard - global config option?
> > From: L. K. [mailto:[EMAIL PROTECTED]] > > I really do not belive that for a CPU or a motherboard +- 1 > > degree would make any difference. > > You haven't pushed your system, or run it in a hostile > environment then. There are many places where systems are run > right up to the edge of thermal breakdown, and it's a firm > requirement to know exactly what that edge is. > I didn't pushed my system because I belive it performs well without overclocking. There are a lot of chances to fry the chip, and for this reason I use my system at the frequency my manufacturer gave it to me. > > > If a CPU runs fine at, say, 37 degrees C, I do not belive it > > will have any problems running at 38 or 36 degrees. I support > > the ideea of having very good sensors for temperature > > monitoring, but CPU and motherboard temperature do not depend > > on the rise of the temperature of 1 degree, but when the > > temperature rises 10 or more degrees. I hope you understand > > what I want to say. > > I have a CPU that runs great up to 43C, and shuts down hard at 44C > so I obviously want to know how close I am to that. I don't want > rounding errors to get in the way, and I don't want changes > between kernel revs to affect it either. > It might be as you say, but I really do not belive that your chip will fry at 44C. I never seen a chip that fried becasue the temperature was 1 degree greater that the one it supposed to work at. And I worked with a lot of CPU's and motherboards. > If we've got the bitspace, keep the counters as granular as > possible within the useable range that we're designing for. > > counter = .01 * degrees kelvin > I said, and now I'll say it again: I support the ideea of having very high precission, BUT this is not the case for personal computer, this may concern high-end systems that must run in a controlled environment at a fixed temperature. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On 9 Jun 2001, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:"Albert D. Cahalan" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > > > But in spite of all this, you're not really measure the critical > > > temperature, which is junction tempature. Yes, case tempature has *some* > > > > There are processors with temperature measurement built right > > into the silicon. > > As far as I know, ALL current microprocessors do. The current x86 setup uses a small sensor sitting under the CPU socket. Intel's more recent output does have a heat sensor of its own, for thermal protection purposes - presumably this is exported to the chipset - but older ones don't appear to... James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
www.bzimage.org: bad intermediate patch 2.4.5-ac9-ac10
We had for an hour or so a bad intermediate diff going from kernel 2.4.5-ac9 to ac10. The size of the patch was 800+ kilobyte. The new "good" one is about 163 kilobyte. If you try to apply the wrong patch, it complains about scsidrivers beeing reversed. Sorry for the troubles. Danny -- Holland Hosting www.hoho.nl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [driver] New life for Serial mice
On Fri, Jun 08, 2001 at 03:19:46PM -0500, Mike Coleman wrote: > Vojtech Pavlik <[EMAIL PROTECTED]> writes: > > > Can't it make mouse jump forward and back when user suddenly stops? > > > > In theory - yes. It doesn't seem to be a problem in practice, though. > > It'll happen when a user slows down the mouse pointer motion faster than > > exponentially (base 2). I haven't been able to stop that fast. > > Put a big brick on your desktop and *ram* it with your mouse. :-) Cool idea! Gotta try ... ;) -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Sat, 9 Jun 2001, Rik van Riel wrote: >> Why are half the people here trying to hide behind this diskspace >> is cheap argument? If we rely on that, then Linux sucks shit. > >Never mind them, I haven't seen any of them contribute >VM code, even ;) Nor have I, but I think you guys working on it will get it cleaned up eventually. What bugs me is people trying to pretend that it isn't important to fix, or that spending money to get newer hardware is acceptable solution. >OTOH, disk space _is_ cheap, so the other VM - performance >related - VM bugs do have a somewhat higher priority at the >moment. Yes, it is cheap. It isn't always an acceptable workaround though, so I'm glad you guys are working on it - even if we have to wait a bit. I have faith in the system. ;o) -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Followup to: <[EMAIL PROTECTED]> By author:"Albert D. Cahalan" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > I hope you don't think people would assume that a "float" always > has useful data in all 23 fraction bits. It is a similar case. > > So here you go, a kernel-safe conversion from C to K. It works > from 0 to 238 degrees C. Print as hex, so user code can toss it > into a union or maybe abuse scanf. Adjust as needed for F to K > or for hardware with greater resolution. > I hope you're not seriously suggesting we're using floats for this... -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, Mike A. Harris wrote: > Why are half the people here trying to hide behind this diskspace > is cheap argument? If we rely on that, then Linux sucks shit. Never mind them, I haven't seen any of them contribute VM code, even ;) OTOH, disk space _is_ cheap, so the other VM - performance related - VM bugs do have a somewhat higher priority at the moment. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Michael H. Warfiel writes:
> On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:
>> The bits are free; the API is hard to change.
>> Sensors might get better, at least on high-end systems.
>> Rounding gives a constant 0.15 degree error.
>> Only the truly stupid would assume accuracy from decimal places.
>> Again, the bits are free; the API is hard to change.
...
> No... The average person, NO, the vast majority of people,
> DO assume accuracy from decimal places and honestly do not know the
> difference between precision and accuracy. I've had comments on this
> thread in private E-Mail the reinforce this impression.
I hope you don't think people would assume that a "float" always
has useful data in all 23 fraction bits. It is a similar case.
So here you go, a kernel-safe conversion from C to K. It works
from 0 to 238 degrees C. Print as hex, so user code can toss it
into a union or maybe abuse scanf. Adjust as needed for F to K
or for hardware with greater resolution.
/* unsigned int degrees C --> float degrees K */
unsigned ic_to_fk(unsigned c){
unsigned exponent;
unsigned tmp;
tmp = (c<<23) + 0x8893; /* Kelvin shifted 23 left */
exponent = 127; /* IEEE floating-point bias */
while(tmp&0xff00){
tmp >>= 1;
exponent++;
}
tmp &= 0x007f; /* keep only the fraction */
tmp |= exponent<<23;
return tmp;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Followup to: <[EMAIL PROTECTED]> By author:"Albert D. Cahalan" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > > But in spite of all this, you're not really measure the critical > > temperature, which is junction tempature. Yes, case tempature has *some* > > There are processors with temperature measurement built right > into the silicon. > As far as I know, ALL current microprocessors do. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
checker suggestion
Struct padding is a problem. Really, there shouldn't be any implicit padding. This causes: 1. security leaks when such structs are copied to userspace (the implicit padding is uninitialized, and so may contain a chunk of somebody's private key or password) 2. bloat, when struct members could be reordered to eliminate the need for padding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] a couple potential deadlocks in 2.4.5-ac8
Hi All, we're starting to develop a checker that finds deadlocks by (1) computing all lock acquisition paths and (2) checking if two paths violate a partial order. E.g., for two threads T1 and T2: T1: foo acquires A --> calls bar which tries to acquire B T2: baz acquires B --> calls blah which tries to acquire A all else being equal, this deadlocks. The checker is pretty primitive. In particular: - lots of false negatives come from the fact that it does not track interrupt disabling. A missed deadlock: foo acquires A bar interrupts foo, disables interrupts, tries to acquire A (Is this the most common deadlock?) - many potential false positives since it does not realize when two kernel call traces are mutually exclusive. To check it's mechanics I've enclosed what look to me to be two potential deadlocks --- given the limits of the tool and my understanding of what can happen when, these could be (likely be?) false positive, so I'd appreciate any corrective feedback. Dawson ERROR: violated partial order [lock_super:sb<--->lock_kernel:$none$] path for lock_super:sb -> lock_kernel:$none$ seems reasonable: all contained in the same FS. path for lock_super:sb -> lock_kernel:$none$ sysv_new_inode:100:lock_super(sb) --> 145:sysv_write_inode -->sysv_write_node:1183:lock_kernel path for lock_kernel -> lock_super:sb sysv_get_block:812:lock_kernel --> 855:block_getblk --> block_getblk:766:sysv_free_block --> sysv_free_block:45:lock_super ERROR: violated partial order [lock_super:sb<--->lock_kernel:$none$] path for lock_super:sb -> lock_kernel:$none$ [BUG] Unless lock_kernel already held, which is certainly possible... path for lock_super:sb -> lock_kernel:$none$ sysv_new_inode:100:lock_super(sb); --> sysv_write_inode:1134:lock_kernel(); path for lock_kernel--> lock_super: fsync_dev:325:lock_kernel --> sync_supers:599:lock_super --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Followup to: <[EMAIL PROTECTED]> By author:Chris Boot <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Well then, tell all the teachers in this world that they're stupid, and tell > everyone who learnt from them as well. I'm in high school (gd. 11, junior) > and my physics teacher is always screaming at us for putting too many > decimal places or having them inconsistent. There are certain situations > where adding a ±1 is too cumbersome and / or clumsy, so you can specify the > accuracy using just decimal places. > This, again, is a presentation issue, and is irrelevant to the intricacies of fixed-point arithmetric. > For example, 5.00 would mean pretty much spot on 5 (anywhere from 4.995 to > 5.00499), wheras 5 could mean anywhere from 4.5 to 5.499. > > Please, let's quit this dumb argument. We all know that thermistors and > other types of cheap temperature gauges are very inaccurate, and I don't > think expensive thermocouples will make it into computer sensors very soon. > Plus, who the hell could care whether their chip is at 45.4 or 45.5 degrees? > Does it really matter? A difference of 0.1 will not decide whether your > chip will fry. Does it really matter NOW? No. However, 1 cK is a convenient unit and a good use of bits. Can we guarantee it won't matter in the future, especially not on a CPU which may very well require complex algorithms to eke out optimal performance in a thermally-challenged environment (more than just simple trip points.) Now it gets interesting! I have actually seen, in the lab, an algorithm which required complex guesswork, because it required information below the noise level of the sensor (and yes, it *is* possible to obtain that information.) -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Followup to: <[EMAIL PROTECTED]> By author:"Michael H. Warfield" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Yes, bits are free, sort of... That's why an extra decimal > place is "ok". Keeping precision within an order of magnitude of > accuracy is within the realm of reasonable. Running out to two decimal > places for this particular application is just silly. If it were for > calibrated lab equipment, fine. But not for CPU temperatures. > Do you want to bet that that is going to remain the case, or are you just assuming the current state of the art will continue to be used forever? That is extremely poor interface design. Designing interfaces is NOT the same thing as judging science fairs and presenting data. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On 6 Jun 2001, Eric W. Biederman wrote: > Derek Glidden <[EMAIL PROTECTED]> writes: > > > The problem I reported is not that 2.4 uses huge amounts of swap but > > that trying to recover that swap off of disk under 2.4 can leave the > > machine in an entirely unresponsive state, while 2.2 handles identical > > situations gracefully. > > The interesting thing from other reports is that it appears to be > kswapd using up CPU resources. This part is being worked on, expect a solution for this thing soon... Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, Derek Glidden wrote: > Or are you saying that if someone is unhappy with a particular > situation, they should just keep their mouth shut and accept it? There are lots of options ... 1) wait until somebody fixes the problem 2) fix the problem yourself 3) start infinite flamewars and make developers so sick of the problem nobody wants to fix it 4) pay someone to fix the problem ;) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, Sean Hunter wrote: > A working VM would have several differences from what we have in my > opinion, among which are: > - It wouldn't require 8GB of swap on my large boxes > - It wouldn't suffer from the "bounce buffer" bug on my > large boxes > - It wouldn't cause the disk drive on my laptop to be > _constantly_ in use even when all I have done is spawned a > shell session and have no large apps or daemons running. > - It wouldn't kill things saying it was OOM unless it was OOM. I fully agree these problems need to be fixed. I just wish I had the time to tackle all of them right now ;) We should be close to getting the 3rd problem fixed and the deadlock problem with the bounce buffers seems to be fixed already. Getting reclaiming of swap space and OOM fixed is a matter of time ... I hope I'll have that time in the near future. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
workaround for all this weirdness in vm?
Is running without swap a possible workaround for all this vm weirdness folks are reporting? Alexander - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Report was:Re: Break 2.4 VM in five easy steps
> reads the RTC device. The patched RTC driver can then > measure the elapsed time between the interrupt and the > read from userspace. Voila: latency. interesting, but I'm not sure there's much advantage over doing it entirely in user-space with the normal /dev/rtc: http://brain.mcmaster.ca/~hahn/realfeel.c it just prints out the raw time difference from when rtc should have woken up the program. you can do your own histogram; for summary purposes, something like stdev is probably best. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Report was:Re: Break 2.4 VM in five easy steps
reads the RTC device. The patched RTC driver can then measure the elapsed time between the interrupt and the read from userspace. Voila: latency. interesting, but I'm not sure there's much advantage over doing it entirely in user-space with the normal /dev/rtc: http://brain.mcmaster.ca/~hahn/realfeel.c it just prints out the raw time difference from when rtc should have woken up the program. you can do your own histogram; for summary purposes, something like stdev is probably best. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
workaround for all this weirdness in vm?
Is running without swap a possible workaround for all this vm weirdness folks are reporting? Alexander - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, Sean Hunter wrote: A working VM would have several differences from what we have in my opinion, among which are: - It wouldn't require 8GB of swap on my large boxes - It wouldn't suffer from the bounce buffer bug on my large boxes - It wouldn't cause the disk drive on my laptop to be _constantly_ in use even when all I have done is spawned a shell session and have no large apps or daemons running. - It wouldn't kill things saying it was OOM unless it was OOM. I fully agree these problems need to be fixed. I just wish I had the time to tackle all of them right now ;) We should be close to getting the 3rd problem fixed and the deadlock problem with the bounce buffers seems to be fixed already. Getting reclaiming of swap space and OOM fixed is a matter of time ... I hope I'll have that time in the near future. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, Derek Glidden wrote: Or are you saying that if someone is unhappy with a particular situation, they should just keep their mouth shut and accept it? There are lots of options ... 1) wait until somebody fixes the problem 2) fix the problem yourself 3) start infinite flamewars and make developers so sick of the problem nobody wants to fix it 4) pay someone to fix the problem ;) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Followup to: [EMAIL PROTECTED] By author:Michael H. Warfield [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Yes, bits are free, sort of... That's why an extra decimal place is ok. Keeping precision within an order of magnitude of accuracy is within the realm of reasonable. Running out to two decimal places for this particular application is just silly. If it were for calibrated lab equipment, fine. But not for CPU temperatures. Do you want to bet that that is going to remain the case, or are you just assuming the current state of the art will continue to be used forever? That is extremely poor interface design. Designing interfaces is NOT the same thing as judging science fairs and presenting data. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On 6 Jun 2001, Eric W. Biederman wrote: Derek Glidden [EMAIL PROTECTED] writes: The problem I reported is not that 2.4 uses huge amounts of swap but that trying to recover that swap off of disk under 2.4 can leave the machine in an entirely unresponsive state, while 2.2 handles identical situations gracefully. The interesting thing from other reports is that it appears to be kswapd using up CPU resources. This part is being worked on, expect a solution for this thing soon... Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Followup to: [EMAIL PROTECTED] By author:Chris Boot [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Well then, tell all the teachers in this world that they're stupid, and tell everyone who learnt from them as well. I'm in high school (gd. 11, junior) and my physics teacher is always screaming at us for putting too many decimal places or having them inconsistent. There are certain situations where adding a ±1 is too cumbersome and / or clumsy, so you can specify the accuracy using just decimal places. This, again, is a presentation issue, and is irrelevant to the intricacies of fixed-point arithmetric. For example, 5.00 would mean pretty much spot on 5 (anywhere from 4.995 to 5.00499), wheras 5 could mean anywhere from 4.5 to 5.499. Please, let's quit this dumb argument. We all know that thermistors and other types of cheap temperature gauges are very inaccurate, and I don't think expensive thermocouples will make it into computer sensors very soon. Plus, who the hell could care whether their chip is at 45.4 or 45.5 degrees? Does it really matter? A difference of 0.1 will not decide whether your chip will fry. Does it really matter NOW? No. However, 1 cK is a convenient unit and a good use of bits. Can we guarantee it won't matter in the future, especially not on a CPU which may very well require complex algorithms to eke out optimal performance in a thermally-challenged environment (more than just simple trip points.) Now it gets interesting! I have actually seen, in the lab, an algorithm which required complex guesswork, because it required information below the noise level of the sensor (and yes, it *is* possible to obtain that information.) -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
checker suggestion
Struct padding is a problem. Really, there shouldn't be any implicit padding. This causes: 1. security leaks when such structs are copied to userspace (the implicit padding is uninitialized, and so may contain a chunk of somebody's private key or password) 2. bloat, when struct members could be reordered to eliminate the need for padding - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] a couple potential deadlocks in 2.4.5-ac8
Hi All, we're starting to develop a checker that finds deadlocks by (1) computing all lock acquisition paths and (2) checking if two paths violate a partial order. E.g., for two threads T1 and T2: T1: foo acquires A -- calls bar which tries to acquire B T2: baz acquires B -- calls blah which tries to acquire A all else being equal, this deadlocks. The checker is pretty primitive. In particular: - lots of false negatives come from the fact that it does not track interrupt disabling. A missed deadlock: foo acquires A bar interrupts foo, disables interrupts, tries to acquire A (Is this the most common deadlock?) - many potential false positives since it does not realize when two kernel call traces are mutually exclusive. To check it's mechanics I've enclosed what look to me to be two potential deadlocks --- given the limits of the tool and my understanding of what can happen when, these could be (likely be?) false positive, so I'd appreciate any corrective feedback. Dawson ERROR: violated partial order [lock_super:sb---lock_kernel:$none$] path for lock_super:sb - lock_kernel:$none$ seems reasonable: all contained in the same FS. path for lock_super:sb - lock_kernel:$none$ sysv_new_inode:100:lock_super(sb) -- 145:sysv_write_inode --sysv_write_node:1183:lock_kernel path for lock_kernel - lock_super:sb sysv_get_block:812:lock_kernel -- 855:block_getblk -- block_getblk:766:sysv_free_block -- sysv_free_block:45:lock_super ERROR: violated partial order [lock_super:sb---lock_kernel:$none$] path for lock_super:sb - lock_kernel:$none$ [BUG] Unless lock_kernel already held, which is certainly possible... path for lock_super:sb - lock_kernel:$none$ sysv_new_inode:100:lock_super(sb); -- sysv_write_inode:1134:lock_kernel(); path for lock_kernel-- lock_super: fsync_dev:325:lock_kernel -- sync_supers:599:lock_super --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Michael H. Warfiel writes:
On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:
The bits are free; the API is hard to change.
Sensors might get better, at least on high-end systems.
Rounding gives a constant 0.15 degree error.
Only the truly stupid would assume accuracy from decimal places.
Again, the bits are free; the API is hard to change.
...
No... The average person, NO, the vast majority of people,
DO assume accuracy from decimal places and honestly do not know the
difference between precision and accuracy. I've had comments on this
thread in private E-Mail the reinforce this impression.
I hope you don't think people would assume that a float always
has useful data in all 23 fraction bits. It is a similar case.
So here you go, a kernel-safe conversion from C to K. It works
from 0 to 238 degrees C. Print as hex, so user code can toss it
into a union or maybe abuse scanf. Adjust as needed for F to K
or for hardware with greater resolution.
/* unsigned int degrees C -- float degrees K */
unsigned ic_to_fk(unsigned c){
unsigned exponent;
unsigned tmp;
tmp = (c23) + 0x8893; /* Kelvin shifted 23 left */
exponent = 127; /* IEEE floating-point bias */
while(tmp0xff00){
tmp = 1;
exponent++;
}
tmp = 0x007f; /* keep only the fraction */
tmp |= exponent23;
return tmp;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Followup to: [EMAIL PROTECTED] By author:Albert D. Cahalan [EMAIL PROTECTED] In newsgroup: linux.dev.kernel But in spite of all this, you're not really measure the critical temperature, which is junction tempature. Yes, case tempature has *some* There are processors with temperature measurement built right into the silicon. As far as I know, ALL current microprocessors do. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, Mike A. Harris wrote: Why are half the people here trying to hide behind this diskspace is cheap argument? If we rely on that, then Linux sucks shit. Never mind them, I haven't seen any of them contribute VM code, even ;) OTOH, disk space _is_ cheap, so the other VM - performance related - VM bugs do have a somewhat higher priority at the moment. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
