Re: [BUG] 2.2.17final crashed Update
| > It screams like a banshee when enabled.
| yup.
| How annoying but interesting. You'd think they'd mention it (ASUS). Do you have
|this
| website anywhere still?
On my hard drive :)
I will repost it soon, hopefully later tonite.
Keep an eye out on http://www.mojomofo.com
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±êçzX§¶¡Ü¨}©²Æ zÚ:+v¨¾«êçzZ+ù^jÇ«y§m
á@A«a¶Úÿ
0¶ìh®åi
Re: [BUG] 2.2.17final crashed Update
Aaron Tiensivu wrote: > | > ASUS P5A with delayed transactions enabled? > | Oh, you know this critter? I'm assuming disabling delayed transactions fixes the > | speaker solos? > > I used to have a website dedicated to all the quirks that motherboard had. :) > > It's either delayed transactions or passive release that causes it. > > It is whatever option is lower in the bios (I have a photographic memory but > otherwise a bad one overall :) ) > > It screams like a banshee when enabled. yup. How annoying but interesting. You'd think they'd mention it (ASUS). Do you have this website anywhere still? -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: Yet another report on the dquot oops
Did you apply the quota patch that was posted this week? -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: [BUG] 2.2.17final crashed Update
| > ASUS P5A with delayed transactions enabled? | Oh, you know this critter? I'm assuming disabling delayed transactions fixes the | speaker solos? I used to have a website dedicated to all the quirks that motherboard had. :) It's either delayed transactions or passive release that causes it. It is whatever option is lower in the bios (I have a photographic memory but otherwise a bad one overall :) ) It screams like a banshee when enabled. ¢éì¹» ®&Þ~º&¶¬+-±éݶ¥w®Ë±Êâmébìdz¹Þ)í æèw* jg¬±¨ ¶Ý¢j/êäz¹Þà>W±êÞiÛaxPjØm¶ÿà -»+ùd_
Yet another report on the dquot oops
Hi all,
Just adding my useless complaints the the list -
Currently running test8-pre1 + rik vm patches, very solid.
Tonight I tried test9-pre1 -
The most common occurrence is that vi segfaults on exit.
Here is a decoded oops immediately after booting test9-pre1:
jjs
--- cut ---
ksymoops 2.3.4 on i586 2.4.0-test9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9/ (default)
-m /boot/System.map (specified)
Unable to handle kernel NULL pointer dereference at virtual address
0034
c014ecf1
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ebx: ecx: 0001 edx: c14ebc00
esi: edi: ebp: esp: cc931efc
ds: 0018 es: 0018 ss: 0018
Process vi (pid: 891, stackpage=cc931000)
Stack: cc931f40 c014fa9a 0001 cc931f70 0195 cc953b20
b50c
cc931fa4 cc931f48 cc931f40 c013ead4 0195 0001
ff86
cc94c940 c012bd6f cc953b20
cc931f70
Call Trace: [] [] [] []
[] []
Code: f6 43 34 40 74 09 31 c0 e9 01 01 00 00 89 f6 8b 53 48 85 d2
>>EIP; c014ecf1<=
Trace; c014fa9a
Trace; c013ead4
Trace; c012bd6f
Trace; c012be3a
Trace; c011d421
Trace; c010a3a3
Code; c014ecf1
<_EIP>:
Code; c014ecf1<=
0: f6 43 34 40 testb $0x40,0x34(%ebx) <=
Code; c014ecf5
4: 74 09 je f <_EIP+0xf> c014ed00
Code; c014ecf7
6: 31 c0 xorl %eax,%eax
Code; c014ecf9
8: e9 01 01 00 00jmp10e <_EIP+0x10e> c014edff
Code; c014ecfe
d: 89 f6 movl %esi,%esi
Code; c014ed00
f: 8b 53 48 movl 0x48(%ebx),%edx
Code; c014ed03
12: 85 d2 testl %edx,%edx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: sb driver oops in 2.4.0-test8 [BUG found]
Today, in a message to Joachim Achtzehnter, Paul Laufer wrote: > > I already sent Linus a patch. It is not test9-pre1. I have attached it > here for you and others on lkml. Please let me know how it works for > you. Patch applies to test7 through test8, and test9-pre1. Yes, this fixes the problem. Thanks, Joachim -- work: [EMAIL PROTECTED] (http://www.realtimeint.com) private: [EMAIL PROTECTED] (http://www.kraut.bc.ca) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.17final crashed Update
Steven Walter wrote: > I posted a few days ago reporting that under normal load on 2.2.17final > would crash under non-strenuous loads. One of the symptoms I reported > was that the system speaker would beep. In fact, the beeps are coming > from the speakers. My soundcard is a CM8738, and so uses the cmpci > driver. Perhaps this is where the bug is coming from? What is odd, is I have a machine that tends to make the speaker blart a lot when I access the floppy drive. I have to access the floppy off and on until it turns off once it gets going. Figure that one out. I have no idea if it's software or hardware, but I'm inclined to the latter. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
[BUG] 2.2.17final crashed Update
I posted a few days ago reporting that under normal load on 2.2.17final would crash under non-strenuous loads. One of the symptoms I reported was that the system speaker would beep. In fact, the beeps are coming from the speakers. My soundcard is a CM8738, and so uses the cmpci driver. Perhaps this is where the bug is coming from? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sb driver oops in 2.4.0-test8 [BUG found]
Yes, its a bug! My fault. I already sent Linus a patch. It is not
test9-pre1. I have attached it here for you and others on lkml. Please
let me know how it works for you. Patch applies to test7 through test8,
and test9-pre1.
Thanks for your time,
Paul Laufer
On Thu, Sep 14, 2000 at 12:10:36AM -0700 or thereabouts, Joachim Achtzehnter wrote:
> Here is some more info about this problem:
>
> The trouble is caused by the driver's attempt to find multiple
> soundblaster cards. Specifying multiple=0 as a module option for sb fixes
> the problem. Note, however, this quote from the Documentation/Soundblaster
> file:
>
> multiple=0Set to disable detection of multiple Soundblaster cards.
> Consider it a bug if this option is needed, and send in a
> report.
>
> So, this is a bug then!
>
> The function init_sb in drivers/sound/sb_card.c contains a detection loop
> from card=0..SB_CARDS_MAX. This doesn't work, however, because the
> second time around it uses the same module parameters (DMA/IRQ/IO) and
> hence attempts to detect the exact same card instance. The result is not
> only that no second card is found, which is ok in my case, but the
> originally detected card is screwed up as well.
>
> I'm not sufficiently familiar with the driver to know what it should
> do. Could it be that once it can't find a card via isapnp it should bail
> out from this loop?
>
> Joachim
>
> --
> work: [EMAIL PROTECTED] (http://www.realtimeint.com)
> private: [EMAIL PROTECTED] (http://www.kraut.bc.ca)
--- linux-virgin/drivers/sound/sb_card.cSat Sep 9 15:06:13 2000
+++ linux/drivers/sound/sb_card.c Sat Sep 9 15:07:16 2000
@@ -647,7 +647,7 @@
static int __init init_sb(void)
{
- int card, max = multiple ? SB_CARDS_MAX : 1;
+ int card, max = (multiple && isapnp) ? SB_CARDS_MAX : 1;
printk(KERN_INFO "Soundblaster audio driver Copyright (C) by Hannu Savolainen
1993-1996\n");
@@ -660,6 +660,7 @@
if(!sb_cards_num) {
printk(KERN_NOTICE "sb: No ISAPnP cards found, trying
standard ones...\n");
isapnp = 0;
+ max = 1;
} else
break;
}
Re: Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8
> Jonathan Earle wrote: > > Hi, > > I've been having kernel oopses with the 2.4.0-test series and am > including ksymoops processed output from both test4 and test5 > kernels. The same oops happens in later kernels too (Tested with > test6, test7 and test8). > Presumably mpls_output() is doing a kmalloc(..., GFP_KERNEL) from within a softirq. Hunt that down and turn it into GFP_ATOMIC. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH *] new VM patch for 2.4.0-test8
On Fri, 15 Sep 2000, James Lewis Nance wrote: > On Fri, Sep 15, 2000 at 10:09:57PM -0300, Rik van Riel wrote: > > Hi, > > > > today I released a new VM patch with 4 small improvements: > > Are these 4 improvements in the code test9-pre1 patch that Linus > just released? No. But I have a patch (that I will mail to the list once I've tested it a bit more). regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH *] new VM patch for 2.4.0-test8
On Fri, 15 Sep 2000, James Lewis Nance wrote:
> On Fri, Sep 15, 2000 at 10:09:57PM -0300, Rik van Riel wrote:
> > Hi,
> >
> > today I released a new VM patch with 4 small improvements:
>
> Are these 4 improvements in the code test9-pre1 patch that Linus
> just released?
Oh well, I may as well give it now ;)
The patch below upgrades 2.4.0-test9-pre1 VM to a
VM with the 4 changes...
They /should/ be stable, but I'd really appreciate
a bit more testing before I give the patch to Linus.
(I know the VM patch included in 2.4.0-test9-pre1 is
stable, that one got a heavier testing than any VM patch
I ever made. I was testing the system so heavily that I
had to upgrade my 8139too driver and other things to keep
the system from crashing ;))
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
--- linux-2.4.8-test9-pre1/fs/buffer.c.orig Fri Sep 15 23:23:09 2000
+++ linux-2.4.8-test9-pre1/fs/buffer.c Fri Sep 15 23:26:24 2000
@@ -705,7 +705,6 @@
static void refill_freelist(int size)
{
if (!grow_buffers(size)) {
- //wakeup_bdflush(1);
balance_dirty(NODEV);
wakeup_kswapd(1);
}
@@ -863,15 +862,14 @@
dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
tot = nr_free_buffer_pages();
-// tot -= size_buffers_type[BUF_PROTECTED] >> PAGE_SHIFT;
dirty *= 200;
soft_dirty_limit = tot * bdf_prm.b_un.nfract;
hard_dirty_limit = soft_dirty_limit * 2;
/* First, check for the "real" dirty limit. */
- if (dirty > soft_dirty_limit || inactive_shortage()) {
- if (dirty > hard_dirty_limit)
+ if (dirty > soft_dirty_limit) {
+ if (dirty > hard_dirty_limit || inactive_shortage())
return 1;
return 0;
}
@@ -2279,7 +2277,9 @@
{
struct buffer_head * tmp, * bh = page->buffers;
int index = BUFSIZE_INDEX(bh->b_size);
+ int loop = 0;
+cleaned_buffers_try_again:
spin_lock(_list_lock);
write_lock(_table_lock);
spin_lock(_list[index].lock);
@@ -2325,8 +2325,14 @@
spin_unlock(_list[index].lock);
write_unlock(_table_lock);
spin_unlock(_list_lock);
- if (wait)
+ if (wait) {
sync_page_buffers(bh, wait);
+ /* We waited synchronously, so we can free the buffers. */
+ if (wait > 1 && !loop) {
+ loop = 1;
+ goto cleaned_buffers_try_again;
+ }
+ }
return 0;
}
--- linux-2.4.8-test9-pre1/mm/swap.c.orig Fri Sep 15 23:23:11 2000
+++ linux-2.4.8-test9-pre1/mm/swap.cFri Sep 15 23:24:23 2000
@@ -161,14 +161,19 @@
* Don't touch it if it's not on the active list.
* (some pages aren't on any list at all)
*/
- if (PageActive(page) && (page_count(page) == 1 || page->buffers) &&
+ if (PageActive(page) && (page_count(page) <= 2 || page->buffers) &&
!page_ramdisk(page)) {
/*
* We can move the page to the inactive_dirty list
* if we know there is backing store available.
+*
+* We also move pages here that we cannot free yet,
+* but may be able to free later - because most likely
+* we're holding an extra reference on the page which
+* will be dropped right after deactivate_page().
*/
- if (page->buffers) {
+ if (page->buffers || page_count(page) == 2) {
del_page_from_active_list(page);
add_page_to_inactive_dirty_list(page);
/*
@@ -181,8 +186,7 @@
add_page_to_inactive_clean_list(page);
}
/*
-* ELSE: no backing store available, leave it on
-* the active list.
+* OK, we cannot free the page. Leave it alone.
*/
}
}
--- linux-2.4.8-test9-pre1/mm/vmscan.c.orig Fri Sep 15 23:23:11 2000
+++ linux-2.4.8-test9-pre1/mm/vmscan.c Fri Sep 15 23:32:10 2000
@@ -103,8 +103,8 @@
UnlockPage(page);
vma->vm_mm->rss--;
flush_tlb_page(vma, address);
- page_cache_release(page);
deactivate_page(page);
+ page_cache_release(page);
goto out_failed;
}
@@ -681,19 +681,26 @@
if (freed_page && !free_shortage())
break;
continue;
+ } else if (page->mapping && !PageDirty(page)) {
+ /*
+* If a page had an extra reference in
+* deactivate_page(), we will
Re: [PATCH *] new VM patch for 2.4.0-test8
On Fri, Sep 15, 2000 at 10:09:57PM -0300, Rik van Riel wrote: > Hi, > > today I released a new VM patch with 4 small improvements: Are these 4 improvements in the code test9-pre1 patch that Linus just released? Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
QLC: Driver Update (fwd)
-- Forwarded message -- Date: Fri, 15 Sep 2000 19:00:06 -0700 From: April Dunbar <[EMAIL PROTECTED]> To: April Dunbar <[EMAIL PROTECTED]> Subject: QLC: Driver Update Good Afternoon, I would like to advise that we have posted the following new driver to our website. Thank you, April Dunbar QLA2x00 REDHAT LINUS v6.2/2.23 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre1
Ok, the new MM balancing has been getting good reviews, and no longer has any known issues. Integrated. We'd have needed to do it sooner or later anyway (just see what happened in 2.2.x), the sooner we do it the less traumatic it will end up being. Oh, and yeah, there obviously was still a truncate issue left. The patch is largish, mainly due SysKonnect and ACPI reorg patches. Linus - pre1: - USB: OHCI controller unlink and bandwidth reclamation fixes - USB: storage update - sparc64: register window race. Non-deadlock rwlocks. - name clash in hamradio/pi2.c and hamradio/pt.c - epic100 credits, 8139too driver update, sr.c initcalls - acenic update - NFS sillyrename fixups - mktime(). Do it just once - not 16 times. - misc small fixes to random drivers by Tigran - IDE driver picks up master/slave relationships on its own. - truncate unmapped/uptodate case handled correctly - don't do notifier locking at low level: higher levels do (or should do) this already. - ACPI interpreter updates (and file renames - making this part big) - SysKonnect gigabit driver update - 3c59x driver update - pcmcia debounce logic. Ugh. - MM balancing (Rik Riel) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Console
> My name is Kirti Desai. I am trying to write a new
> console driver.
No problem. What are you looking to do?
> * Is console related to a tty_driver?
A tty is a posix terminals which cover alot of different types of
hardware. Everything from modems to serial consoles to video terminals
which use hardware like VGA video cards. If you are talking about
video consoles (VTs) then they are a subset of ttys types. Remember their
are many types of ttys.
> We have two functions register_console and register_tty_driver? How are
> these two related?
As for register_console you are talking about the system console.
This is the console where things like kernel errors printed via printk
go. Note any kind of tty can be a system console.
> In tty_init(tty_io.c) we register dev_tty_driver and
> dev_syscons_driver?
> In console_init(tty_io.c) con_init(tty_io.c for
> CONFIG_VT=y) is
> called. It registers console_driver and calls
> register_console(vt_console_driver).
This is registering a video terminal (VT) as a system console. Thus
printks will be sent to this terminal.
> * To do printk we need not open the /dev/console file?
Printk is handled inside the kernel. Take a look at linux/kernel/printk.c.
What do you mean by open? Via userland ?
> What I found was
> start_kernel(init/main.c) calls console_init and
> kernel_thread(init..)
> which calls init is called later which opens
> /dev/console.
Right. First we initalize the the basic termios structure and startup up
hardware that can be started early. Later on other types of hardware which
depend on other subsystems running such as the PCI bus are called in
tty_init. Next /dev/console is opened. I believe this is the first opened
file in a linux system thus its file descriptor is 0. It is stdin. With
dup we set stdin, stdout, and stderr all equal to each other.
if (open("/dev/console", O_RDWR, 0) < 0)
printk("Warning: unable to open an initial console.\n");
(void) dup(0);
(void) dup(0);
Then init is started after the kernel is done. It is the father of all
process. It uses the file /etc/inittab to setup all your consoles.
> * How are stdin/stdout/stderr mapped to the tty's?
See above.
> What want to know
> if that when we call say printf in user
> program,finally write(1,..) gets called which calls
> tty_write ,con_write. How does tty come in
> picture?
printf sends by default data to stdout whcih goes to /dev/console threw
the tty layer to con_write if it is VT.
> * What are /dev/console /dev/tty0, /dev/tty1 files?
/dev/console is the system console (where the printk go). /dev/tty
represents the current console for the current process. If I'm on a serial
console and do a echo "hi" > /dev/tty it will print out on the screen. If
I'm using a console run by fbcon it will do the same thing. Now /dev/tty0
represents the current foreground video console. If you do a echo to
/dev/tty0 it will be printed on the current video display. /dev/tty1 and
so on represent the virtaul consoles for VTs. Those are the consoles you
switch to when you press Alt-F[1-6].
> Any pointer to documentation ..would be of great
> help?
Not alot. This is a linux console project which just started. See the
address in my sig.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [[EMAIL PROTECTED]] /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, [ISO-8859-1] Gérard Roudier wrote: > > > On Fri, 15 Sep 2000, Linus Torvalds wrote: > > > On Fri, 15 Sep 2000, Gérard Roudier wrote: > > > [Snipped a lot...] > > Call "pci_enable_device()". > > > > What's so hard about that? > > This function delegates too much as a whole to the PCI generic layer, IMO. > Imagine that for sanity I want to allocate all the device resources, but > only _enable_ part of device features (for example only memory > transactions). Imagine some special handling to be necessary due to some > chip bug. > It's not just 'maybe'. The Tundra Universe chip for interface to the VXI bus (PCI interface to VXI) allows that either/or/both I/O and memory 'windows' can be enabled. VXI bus space is duplicated in both so it's possible to do everything memory-mapped or even (if you really wanted to) from I/O space. > > You don't seem to realize, but it's entirely possible to have a setup > > where some device CANNOT be allocated it's IO region. The BIOS may have > > left the device disabled on purpose, simply because there wasn't enough > > free space in the memory map to enable the device anywhere. > > PCI specs said corresponding BAR must be set to ZERO, here. > Correct. If there are no resources, you clear all address bits. > > You can't just have the device driver enable such a device. It _has_ to > > ask the PCI layer to do it for it - because the PCI layer is the only one > > that can figure out that "Oh, damn, this machine has 3GB of memory, and 4 > > video cards that want a 256MB aperture each, and we don't have any place > > to map this card any more". > > I want to say the generic layer "What to do" in some more fine-grained way > than just a single verb, at least. I may accept to delegate it some "How > to do it". > > > No ifs, why's or buts. A driver that just enables the IO windows is a > > buggy driver. > > In PCI, you donnot enable windows, but you enable/disable devices to > generate and/or respond to transactions. Well really? From the programmers point-of-view, you have just enabled some windows into address space. The word "transaction" has gotten way too much visibility. The fact that some hardware mechanism has gotten involved reading from and writing to a device means nothing except that a write (if enabled) is posted. We don't bother thinking about "transactions" when we write to SDRAM do we? To the programmer, we write to it and it sticks. The fact that there was a hardware transaction involving a read/modify/write of (usually) much more than our byte isn't a concern. As previously stated (under flames), there are only two kinds of "transactions" you need to be concerned about, the first is, or should be, never used anymore (special cycles), and the second is a configuration transaction. These are important in that a current read/write cycle is aborted for such a transaction. Therefore, you don't want to access configuration space dynamically (like for turning ON/OFF device interrupts). PCI configuration space should only be accessed as required during device startup. OTOH, if you look at all the bits > in the COMMAND register, you will see that some other features are also to > be addressed by the enabling/disabling kernel interface. > I think the idea of accessing the PCI bus as a logical object, where the OS 'knows' the best way to do it is a good thing. However, the driver is going to have to pass much more information to the procedure than a simple pci_enable_device(dev). This has particular importance in PPC and other Motorola-type machines where there isn't any I/O space, but hardware emulates it as a memory access. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: nfs v3 (fwd)
"Albert D. Cahalan" <[EMAIL PROTECTED]> said: > For the benefit of some disbelievers, here we go again, just today. > Somebody, not be be named, was caught jumping ship due to NFS. Strange. I'm running plain 2.2.18pre on PCs, SPARC and Alpha, it works fine with Solaris NFS (as client and server) AFAIS. Machines run either up to date RH 6.2 or a mildly hacked version thereof. So far I haven't seen the dire consecuences of NFS on Linux that are supposed to make people leave in droves... I'd suspect they leave because NFS the protocol (or their setup) is broken, and blame the system. Sure, NFSv3 would mitigate some problems here, but nothing mission-critical for me at least. OTOH, 2.4.0-test NFS doesn't work for me: Can mount fine from Solaris, exporting to Solaris or 2.2.18pre just doesn't work at all. Might be utility problems, but nfsutils-0.2 doesn't work with plain 2.2.18pre, and the NFS patches get a huge reject in fs/nfs/dir.c and fishy-looking offsets elsewhere on 2.2.18pre6 at least. Anyway, if they leave Linux this way they werent't true believers in te first place, were they? ;-) -- 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] Please read the FAQ at http://www.tux.org/lkml/
stuck on TLB IPI wait (CPU#0) at 2.2.17+reiserfs+ide+raid
Hi! few weeks ago, I installed a PROMISE Ultra66 IDE card into my SMP Linux box. But my box sometimes hang up at high load avarage with "stuck on TLB IPI wait (CPU#0)" messages. I upgrade my kernel to 2.2.17 but it also hangs. My kernel is linux-2.2.17 with following pathes. linux-2.2.17-reiserfs-3.5.25-patch.gz ide.2.2.17.all.2904.patch.bz2 raid-2.2.17-A0 Without reiserFS and ide patch, My box worked very well at 2.2.16+raid patch. Please show me what to report to contribute to kernel hackers. Some infomation; = /proc/ide/pdc202xx PDC20262 Chipset. --- General Status --- Burst Mode : enabled Host Mode: Normal Bus Clocking : 33 PCI Internal IO pad select: 4 mA Status Polling Period: 0 Interrupt Check Status Polling Delay : 0 --- Primary Channel Secondary Channel --- enabled enabled 66 Clocking enabled enabled Mode MASTER Mode MASTER FIFO Empty FIFO Empty --- drive0 - drive1 drive0 -- drive1 DMA enabled:yes no yes no DMA Mode: UDMA 4 NOTSET UDMA 4NOTSET PIO Mode: PIO 4NOTSET PIO 4NOTSET = /proc/mdstat Personalities : [raid1] read_ahead 1024 sectors md0 : active raid1 hdg4[1] hde4[0] 15607040 blocks [2/2] [UU] resync=34% finish=110.1min unused devices: = /proc/version Linux version 2.2.17-reiserfs-3.5.25-ide.all.2904-RAID ([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease)) #2 SMP Sat Sep 9 17:44:48 JST 2000 = /proc/interrupts CPU0 CPU1 0: 195968 196009IO-APIC-edge timer 1:301276IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 0 1IO-APIC-edge rtc 13: 1 0 XT-PIC fpu 15: 0 0IO-APIC-edge ide1 16: 271935 271902 IO-APIC-level ide2, ide3 17: 2200 2085 IO-APIC-level eth0 18: 7 7 IO-APIC-level ncr53c8xx NMI: 0 ERR: 0 = /proc/modules nfsd 144996 8 (autoclean) lockd 32712 0 (autoclean) [nfsd] sunrpc 56004 0 (autoclean) [nfsd lockd] eepro100 16568 1 (autoclean) raid1 8292 1 ncr53c8xx 53392 0 (unused) sd_mod 17512 0 (unused) scsi_mod 61880 2 [ncr53c8xx sd_mod] Best Regards, -- W [EMAIL PROTECTED] |O-O| Hisaaki Shibata @ Fukuoka-shi, JAPAN 0(mmm)0 P-mail: 070-5419-3233IRC: #luky ~http://his.luky.org/ last update:2000.3.12 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
> > " " == James Yarbrough <[EMAIL PROTECTED]> writes: > > > What is done for bypassing the cache when the size of a file > > lock held by the reading/writing process is not a multiple of > > the caching granularity? Consider two different clients with > > processes sharing a file and locking 2k byte regions of the > > file and possibly updating these regions. Suppose that each > > system caches 4k byte blocks. If system A locks the first 2k > > of a block and system B locks the second 2k, the updates from > > one of the systems may be lost if these systems cache the > > writes. This is because each system will write back the 4k > > block it cached, not the 2k block that was locked. > > Under Linux writebacks have byte-sized granularity. If a page has been > partially dirtied, we save that information, and only write back the > dirty areas. As long as each system has restricted its updates to > within the 2k block that it has locked, there should be no conflict. > > If however one system has been writing over the full 4k block, then > there will indeed be a race. Using a page cache when locking is turned on is tricky at best. The only working optimizations I know of in this area are allowing the use of page cache when the entire file is locked. My two cents ... Focus on correctness and do the expedient thing first, which is: - The first time a file is locked, flush dirty pages to the server, and then invalidate the page cache - While the file is locked, do vypass the page cache for all I/O. Once that works, the gaping wound in the Linux NFS/NLM client will be closed. This will give you the breathing room to experiment with something that works more optimally (yet still correctly) in some conditions. E.g., one possible optimization is to allow page I/O as long as the locks are page aligned or whole file aligned. -mre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RAID HW Questions...
Well. Since DPT rammed me in the ass with their "SmartRAID V" RAID I need to buy a new RAID card. I don't know who to trust. I was told (about 1 year ago) that DPT was the Co. that liked/worked with the linux community. Obviously they don't. I don't a driver for over $12,000 in RAID HW. So, What RAID card (for RAID 5 or 0/1) is supported under linux? When I mean supported, I mean not some crap ass driver written by an intern. I want something that inspires love from the author. I want a driver that works. Something I don't need to worry about through Kernel version 3.x.x. In other words, something GPLed and Open. I don't care who makes the card, I just want it to be well supported in Linux. (I also Obviously want something fast etc). To sum up: Who out there (for the HW RAID stuff) really works with the Linux Kernel Developers? ie What HW vendor? If this seems a bit offtopic then please just reply off-list. (I do subscribe and have been reading for under a year now). --- Bryan Whitehead UTA - Space and Science Division. Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
[1.] Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
[2.] Programs which read from /proc/tty/driver/serial (using stdio?) will
terminate prematurely with a segmentation fault [SIGSEGV] and do not
produce a corefile.
This was discovered running the sysstat 3.4.2 sadc program which collects
data for sar system activity reporting.
Example:
$ cat /proc/tty/driver/serial
serinfo:1.0 driver:4.27
0: uart:16550A port:3F8 irq:4 baud:9600 tx:11 rx:0
1: uart:16550A port:2F8 irq:3 baud:9600 tx:11 rx:0
2: uart:unknown port:3E8 irq:4
3: uart:unknown port:2E8 irq:3
...
28: uart:unknown port:160 irq:12
29: uart:unknown port:1Segmentation fault
strace output shows that the SIGSEGV occurs in the read system call
open("/proc/tty/driver/serial", O_RDONLY|O_LARGEFILE) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "serinfo:1.0 driver:4.27\n0: uart:"..., 512) = 512
write(1, "serinfo:1.0 driver:4.27\n0: uart:"..., 512serinfo:1.0 driver:4.27
0: uart:16550A port:3F8 irq:4 baud:9600 tx:11 rx:0
...
read(3, "14: uart:unknown port:0 irq:0\n15"..., 512) = 512
write(1, "14: uart:unknown port:0 irq:0\n15"..., 51214: uart:unknown port:0
irq:0
15: uart:unknown port:0 irq:0
...
read(3,
+++ killed by SIGSEGV +++
[3.] kernel old_mmap /proc/tty/driver/serial
[4.] Linux version 2.2.14-5.0 ([EMAIL PROTECTED]) (gcc version
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Mar 7 21:07:39 EST
2000
[5.] No applicable Oops
[6.]
#! /bin/sh
cat /proc/tty/driver/serial
[7.] Uniprocessor HP Vectra VL
[7.1.] sh ver_linux
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux ciemo-linux.sfo.logictier.com 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST
2000 i686 unknown
Kernel modules found
Gnu C egcs-2.91.66
Binutils 2.9.5.0.22
Linux C Library..
ldd: missing file arguments
Try `ldd --help' for more information.
ls: /usr/lib/libg++.so: No such file or directory
Procps 2.0.6
Mount 2.10f
Net-tools (1999-04-20)
Kbd[option...]
Sh-utils 2.0
Sh-utils Parker.
Sh-utils
Sh-utils Inc.
Sh-utils NO
Sh-utils PURPOSE.
[7.2.]cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping: 3
cpu MHz : 501.142695
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr xmm
bogomips: 499.71
[7.3.] cat /proc/modules
autofs 9092 1 (autoclean)
lockd 30344 1 (autoclean)
sunrpc 52132 1 (autoclean) [lockd]
3c59x 18980 1 (autoclean)
[7.4.] cat /proc/scsi/scsi
Attached devices: none
[7.5.] No other useful info from /proc
[X.]
See "/proc/tty/driver/serial kernel oops and other problems -- FIX" which
may
have applicability as a diagnosis of the problem and a proposed fix. The
bug
exists in 2.2.14 kernels, not just in 2.3.5 kernels as indicated by author.
http://uwsg.ucs.indiana.edu/hypermail/linux/kernel/9910.3/0091.html
See "sysstat 3.2.4" from Sebastian Godard
http://www.icewalk.com/softlib/app/app_00904.html
<>
David Ciemiewicz (E-mail).vcf
Re: (reiserfs) Re: More on 2.2.18pre2aa2
On Tue, Sep 12, 2000 at 04:30:32PM +0200, Jamie Lokier wrote: > Sure the global system is slower. But the "interactive feel" is faster. Let's pop up little buttons to make it "feel" faster. -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: ds.o fails to properly enable CardBus card (2.4.0t8)
On Sat, Sep 16, 2000 at 01:02:10AM +0200, Dag B wrote: > > cs: cb_alloc(bus 4): vendor 0x115d, device 0x0003 > PCI: Failed to allocate resource 1 for PCI device 115d:0003 > PCI: Failed to allocate resource 2 for PCI device 115d:0003 > PCI: Failed to allocate resource 6 for PCI device 115d:0003 This part appears to be a PCI bug; it is not allocating the memory resources for the card successfully. The message is not particularly helpful, however. > So: the PCI code says that the last bus is '1', but my CardBus bus #4. > Is this expected? I don't think this is a problem. > I also notice that if I insmod/rmmod ds.o multiple times, I will get > multiple entries for the devices on the card in the 'lspci' output: > > 04:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) > 04:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) This is a PCMCIA bug and appears to not be 2.4 specific; luckily there is an easy workaround: don't insmod/rmmod ds.o ;) I'll fix this. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Card services & yenta driver
On Fri, 15 Sep 2000, David Hinds wrote:
> >
> > socket->events = 0;
> >
> > to "yenta_get_status()". Nothing more, nothing less.
>
> I think this is a bad idea. Ignoring latched events and relying on
> the current socket status is unsafe. You can ignore transient
> card-detect events when the driver hasn't yet started the power up
> sequence, but you cannot ignore them at other times, because the
> bridge does stuff (like cutting power, and redetecting card type) on
> its own.
Hmm.. You're probably right.
It still implies to me that the cs.c code is doing things at too low a
level - it does stuff at a controller level which means that the actual
low-level driver has a hard time trying to figure out what the CS level
really wants. For example, if the higher levels just had a "set power
state" thing, the low-level driver could know that the higher levels want
to change power, and more-over the low-level driver might be able to make
a decision based on that ("it's powering up the card, so I can get rid of
old events").
Right now, the low-level driver has no clue, it just has to assume that
any "set_socket()" call might be a power-up event, for example. It can
compare the new voltage to the one it has programmed in the controller,
but as Andrew pointed out that isn't actually even reliable - because
reading the power level is not going to actually tell you if the
controller had shut off power on its own for some reason.
I don't like Andrew's patch: I see why he does what he does, but it feels
like papering over the real problem which is that the interfaces are just
too opaque for the cs.c code to easily tell the controller what to do, and
vice versa. They both have state, and neither of them can look at the
others state, even though they are really talking about the same thing.
I don't like this "pass hints around" approach. Why not say outright what
you want done, instead of having magic flags that in combination with
other magic flags imply what is going on?
Actually, I'd love to just clear the events _after_ we have passed them
off to the cs layer (instead of before), but that would be inherently
racy, and we might end up missing a valid event if it came in at just the
right time. But a "acknowledge events" callback might work (ie the CS
layer would do a "acknowledge card present change" callback after it was
happy with the situation and had powered up the new card).
Or, we could just do the initial debouncing, all the SS_PENDING etc stuff
in the low-level driver. Which would side-step the communication issue
completely...
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH *] VM patch for 2.4.0-test8]
On Fri, 15 Sep 2000, safemode wrote: > [where to get the VM patch] http://www.surriel.com/patches/ Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Will Riel's vmpatch make it into 2.4.0-test9?
Hello... Just a question from a user... :) I was just wondering if Rik van Riel's VM patches might possibly be integrated into 2.4.0-testX anytime soon? I have been having very good experiences with Riel's latest patches in both a desktop and light server environment. On the desktop, Riel's vmpatch against 2.4.0-test8 is significantly better then 2.4.0-test8's performance. Operation seems much faster and smoother. In fact, I'd say it could even be much better then whats floating around in 2.2.x now! Just a couple of examples on where the differences in Riel's patches become apparent (though one might argue that they are useless indicators) I have recently been having difficulty with Loki Games's latest patches for the game Unreal Tournament. The problem is it leaks memory very quickly. After about two minutes of gameplay the process takes up 300+MB of memory with an increase of around 10mb per minute. This machine only has 256mb of ram so you can imagine that it starts to swap at that point. Usually under 2.2.x it takes about 4 minutes of gameplay before I hear my harddrive screetch and the game starts becoming unresponsive. With Riel's patch and 2.4.0-test8, I can sometimes play for up to 6 minutes before the swapping makes the game unusual. Is Riel's patch more efficient at swapping or something? Another example... Start Quake3, join a game on the internet and play for about 5 minutes. Then quit and go right back into the game. With Riel's patch the harddrive is only touched for a brief second. With 2.2.x the harddrive is touched for a few seconds while quake3 loads the maps, etc that were played before. Riel's patch seems to keep things cached in memory much more efficiently. And yet another example... mkisofs on my system is a dog with 2.4.0-test8. It kills performance of other applications and makes mp3 players skip etc. There is no skipping and "freezeups" with Riel's patch. Although mkisofs seems slower under 2.4.0-test8+vmpatch then stock 2.2.x, Riel's VM seems to be much "smoother". I tried Riel's patch on a lightly loaded webserver. Though because of the lack of any substantial load on the system I don't think its worth commenting on it... Perhaps other people could comment on their experiences? I am looking forward to vmpatch with the planned IO tweaks and out of memory handler... I would hate to have to patch the VM system throughout the 2.4.x stable tree with his patch so I'm lobbying for it to be included. :) Just my opinions and experiences... please feel free to flame away if I am misunderstanding something... Thanks for your time. -- Bruce A. Locke [EMAIL PROTECTED] "The Internet views censorship as damage and routes around it" www.eff.org www.peacefire.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH *] VM patch for 2.4.0-test8]
Jamie Lokier wrote: > Martin Josefsson wrote: > > I've been trying to get my machine to swap but that seems hard with this > > new patch :) I have 0kB of swap used after 8h uptime, and I have been > > compiling, moving files between partitions and running md5sum on files > > (that was a big problem before, everything ended up on the active list and > > the swapping started and brought my machine down to a crawl) > > No preemptive page-outs? > > 0kB swap means if you suddenly need a lot of memory, inactive > application pages have to be written to disk first. There are always > inactive application pages. > > Maybe the stats are inaccurate. Or it just means he hasn't tried compiling mozilla.. which crashes my box every time ...not sure if it's the VM patch to the pre-test8 kernel i'm using or if it's the patch along with the A0 (low latency) patch i'm also using. Also, where are the VM patches being held, i need to get a newer one..this one is unstable.
Re: Q: sock output serialization
> LAPB itsself should be able to recover from reordering, although it is > not optimzed for this. It will just discard any received out-of-sequence > frame. The discarded frames will be retransmitted later (exacly like > frames which had been discarded due to CRC errors). LAPB does not expect ever to see re-ordering. Its a point to point wire level MAC protocol. > For drivers using the software lapb module implementation, the right fix > would obviously be to move the lapb processing above the network interface. Agreed > However, for drivers which support intelligent controllers (with lapb > in firmware) this is not an option and the problem will persist. 'Smart hardware is broken' repeat .. ;) - but yes its an issue there. These cards could bypass netif_rx and call directly to the lapb top end though ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Q: sock output serialization
Hi, > "David" == David S Miller <[EMAIL PROTECTED]> writes: David>It smells rotten to the core, can someone tell me David> exactly why reordering is strictly disallowed? I do not David> even know how other OSes can handle this properly since David> most, if not all, use the IRQ dynamic cpu targeting David> facilities of various machines so LAPB is by definition David> broken there too. LAPB itsself should be able to recover from reordering, although it is not optimzed for this. It will just discard any received out-of-sequence frame. The discarded frames will be retransmitted later (exacly like frames which had been discarded due to CRC errors). The problem is the X.25 packet layer (layer 3). It assumes that the LAPB layer has already fixed any lost frames and out-of-sequence problems and therefor does not provide for an own error recovery mechanism. It will detect when frames are missing or out of sequence. But as it cannot recover from such errors, it will just initiate a reset procedure (discarding all currently queued frames, set the state machine to a known state, and tell the network and the peer to also do so, before data transmission resumes. The upper layer is notified about the reset event, the task to recover from the packet loss is left to the upper layer.) David>I sense that usually, LAPB handles this issue at a David> different level, in the hardware? Does LAPB specify how to David> maintain reliably delivery and could we hook into this David> "how" when we need to drop LAPB frames? Perhaps it is too David> late by the time netif_rx is dealing with it. The lapb protocol allows to flow control the peer. So, if known in advance that netif_rx() would discard the frame, it could set its rx_busy condition. (The linux software lapb module however does not support this, but this problem is yet a different matter). From looking at the netif_rx() source, it seems that CONFIG_NET_HW_FLOWCONTROL almost could provide the necessary state information for flow controling the peer. David> LAPB sounds like quite a broken protocol at the moment... David> But I'm sure there are details which will emerge and clear David> this all up. Well, not just at the moment, it has ever been like this. Thus, as we did not panic before, there is neither reason to panic now. Actually, its not the LAPB protocol itsself that is broken, but the way of accessing it from the X.25 packet layer (reliable datalink service is accessed via the unreliable dev_queue_xmit()/netif_rx() interface). I always wondered why it was done like this. Probably the possible problems were not realized during the early design stage and did not show up when testing. (The problems might be unlikly to occur in real-world scenarios. As real-world X.25 connections usually use only slow links (a few kByte/sec), it is very unlikly that the X.25 connection itsself caused the NET_RX queue to overrun. It might only be triggered when the host is simultaneously flooded with other traffic from a local high speed lan network interface. Triggering SMP packet reordering problems with a slow X.25 link is probably even more unlikely). For drivers using the software lapb module implementation, the right fix would obviously be to move the lapb processing above the network interface. (We will need to provide a function call interface between X.25 packet layer and the datalink layer anyway once LLC.2 from the Linux-SNA project is merged and should be supported by X.25 as well). However, for drivers which support intelligent controllers (with lapb in firmware) this is not an option and the problem will persist. Henner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops with 2.4.0-test8/Token Ring/Netscape
Hello *, this is a bug report about an Oops I get sometimes with kernel 2.4.0-test8; usually it is triggered by reading newsgroups in Netscape 4.75. I know Netscape is not quite bugfree yet, but at least it shouldn't be allowed to do something this bad. I'm using SuSE 7.0 on a ThinkPad 600X (2645-4EU), with a 500MHz Pentium III, 192M RAM (191M usable -- the int15/e820 memory detection doesn't work) and a Turbo 16/4 PCMCIA Token Ring card. The Oops is generated by a BUG() in ll_rw_blk.c. I'm quite sure this only happens when the network is active. I'll include the output of ksymoops and my kernel configuration. Since I'm not subscribed to the mailing list, I would appreciate a Cc: of any replies. The line in the syslog that precedes the Oops is Sep 14 20:13:21 hexane kernel: kernel BUG at ll_rw_blk.c:711! ksymoops ksymoops 0.7c on i686 2.4.0-test8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test8/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Sep 14 20:13:21 hexane kernel: invalid operand: Sep 14 20:13:21 hexane kernel: CPU:0 Sep 14 20:13:21 hexane kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Sep 14 20:13:21 hexane kernel: EFLAGS: 00010282 Sep 14 20:13:21 hexane kernel: eax: 001f ebx: c4722720 ecx: cb12ee60 edx: 0001 Sep 14 20:13:21 hexane kernel: esi: c4722720 edi: c02449c0 ebp: 0001 esp: c9793ea8 Sep 14 20:13:21 hexane kernel: ds: 0018 es: 0018 ss: 0018 Sep 14 20:13:21 hexane kernel: Process netscape (pid: 949, stackpage=c9793000) Sep 14 20:13:21 hexane kernel: Stack: c01c3b85 c01c3e22 02c7 c4722720 0001 000c c9793f0c Sep 14 20:13:21 hexane kernel:c02449d8 c02449d0 0008 c0152702 00fe Sep 14 20:13:21 hexane kernel:c01532c1 c02449c0 0001 c4722720 c4722720 0001 c9793f38 Sep 14 20:13:21 hexane kernel: Call Trace: [] [] [] [] [] [] [] Sep 14 20:13:21 hexane kernel:[] [] [] [] [] [] Sep 14 20:13:21 hexane kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 40 90 23 c0 >>EIP; c0152cbd <__make_request+a1/5a4> <= Trace; c01c3b85 Trace; c01c3e22 Trace; c0152702 Trace; c01532c1 Trace; c0153421 Trace; c01239c5 Trace; c0123a64 Trace; c0123ab5 Trace; c012398c Trace; c01477ab Trace; c012d00b Trace; c012de61 Trace; c010a2d7 Code; c0152cbd <__make_request+a1/5a4> <_EIP>: Code; c0152cbd <__make_request+a1/5a4> <= 0: 0f 0b ud2a <= Code; c0152cbf <__make_request+a3/5a4> 2: 83 c4 0c add$0xc,%esp Code; c0152cc2 <__make_request+a6/5a4> 5: 0f b6 46 15 movzbl 0x15(%esi),%eax Code; c0152cc6 <__make_request+aa/5a4> 9: 0f b7 4e 14 movzwl 0x14(%esi),%ecx Code; c0152cca <__make_request+ae/5a4> d: 8b 14 85 40 90 23 c0 mov0xc0239040(,%eax,4),%edx 1 warning issued. Results may not be reliable. end ksymoops The default file locations are ok, so the warning should not be that important. .config # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_M686FXSR=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_BYTES=32 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_MCA is not set
Re: [patch] Card services & yenta driver
On Fri, Sep 15, 2000 at 02:49:35PM -0700, Linus Torvalds wrote: > > The patch looks ok, but the SS_DEBOUNCE thing is horrible. > > Why do it? All of the SS_DETECT logic is inside cs.c anyway. Now you > introduce SS_DEBOUNCE to fix a cs.c bug, and "export" that cs.c logic bug > into the low-level driver. > > An alternative, and probably more logical, fix is much simpler: add a > simple > > socket->events = 0; > > to "yenta_get_status()". Nothing more, nothing less. I think this is a bad idea. Ignoring latched events and relying on the current socket status is unsafe. You can ignore transient card-detect events when the driver hasn't yet started the power up sequence, but you cannot ignore them at other times, because the bridge does stuff (like cutting power, and redetecting card type) on its own. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
> For 2.2, it's probably better to leave things as they are and just ask PPC > guys for adding a special fixup to their code. I'd rather they added a pci_enable_device(). Lets do it right and encourage easily ported drivers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH *] VM patch for 2.4.0-test8
On Fri, 15 Sep 2000, Jamie Lokier wrote: > Martin Josefsson wrote: > > I've been trying to get my machine to swap but that seems hard with this > > new patch :) I have 0kB of swap used after 8h uptime, and I have been > > compiling, moving files between partitions and running md5sum on files > > (that was a big problem before, everything ended up on the active list and > > the swapping started and brought my machine down to a crawl) > > No preemptive page-outs? Yes. The system tries to keep about 1 second worth of allocations on the inactive list (+ freepages.high). If you're allocating lots of memory very fast, the system /will/ try to swap out things beforehand... > 0kB swap means if you suddenly need a lot of memory, inactive > application pages have to be written to disk first. There are > always inactive application pages. Indeed there are, but since we don't do physical page based scanning yet, we don't deactivate pages from the RSS of processes in the background yet ... (that's a 2.5 issue) > Maybe the stats are inaccurate. Nope. The stats are just fine ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Gérard Roudier wrote: > This function delegates too much as a whole to the PCI generic layer, IMO. > Imagine that for sanity I want to allocate all the device resources, but > only _enable_ part of device features (for example only memory > transactions). Imagine some special handling to be necessary due to some > chip bug. Blindly enabling PIO on VGA devices is bad news, cuz they all want to grab 0x3?0 ports. I always imagined it as something of a special case though. So for VGA devices I agree with you -- I don't care how a device is "enabled", but it would be nice tell the PCI layer that PIO or MMIO bits in PCI_COMMAND need special handling. PCI_DONT_TOUCH_PIO and PCI_DONT_TOUCH_MMIO maybe :) Jeff -- Jeff Garzik | Would you *really* want to Building 1024| get on a non-stop flight? MandrakeSoft, Inc. | -- George Carlin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MakeFile Problems - make modules_install test8
On Fri, 15 Sep 2000 11:32:36 -0700,
Michael Peddemors <[EMAIL PROTECTED]> wrote:
>When running `make modules_install` it errors out with an
>
>cd /lib/modules/2.4.0-test8; \
>mkdir -p pcmcia; \
>find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
>if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.0-test8; fi
>modprobe: kernel: QM_SYMBOLS: Function not implemented
>make: *** [_modinst_post] Error 1
>
>even tho pcmcia was never defined in the .config
Not pcmcia, that error is coming from modprobe. At a guess (and I have
to guess because you did not supply any data about your machine), you
are compiling on a kernel without modules. Something is invoking
modprobe while executing those commands, which is strange because
modprobe is not needed there.
Building the pcmcia directory is a temporary measure until everybody
upgrades to a recent pcmcia-cs. The worst it will do is build an empty
/lib/modules/2.4.0-test8/pcmcia directory.
Stick the commands below in a file then, as root,
strace -f -o modprobe.strace sh -x filename >modprobe.sh 2>&1
mail me the modprobe.strace and modprobe.sh output. Also include the
output from "sh scripts/ver_linux".
cd /lib/modules/2.4.0-test8;
mkdir -p pcmcia;
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.0-test8; fi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Card services & yenta driver
On Wed, 13 Sep 2000, Andrew Morton wrote: > > Finally some clarity with what is going on inside this Dell CPx650 > laptop (TI PCI1225 Cardbus bridge). Yes, it _is_ contact bounce. It > seems to find the 3com NIC particularly offensive - the card can easily > bounce out 150 milliseconds after the first insertion interrupt. The patch looks ok, but the SS_DEBOUNCE thing is horrible. Why do it? All of the SS_DETECT logic is inside cs.c anyway. Now you introduce SS_DEBOUNCE to fix a cs.c bug, and "export" that cs.c logic bug into the low-level driver. An alternative, and probably more logical, fix is much simpler: add a simple socket->events = 0; to "yenta_get_status()". Nothing more, nothing less. Why? Because the whole point of the socket->handler() callback is to tell the cs layer that something new happened. But if the cs layer already did a "get_status()", then obviously the event is no longer "new". So it should be cleared out. Sensible? Also, I'd be a lot happier just changing all timeouts to microseconds. "centiseconds" really don't exist as a valid amount of time. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Linus Torvalds wrote: > On Fri, 15 Sep 2000, Gérard Roudier wrote: > > > > > Just as an example: imagine that the IO windows haven't been set up > > > correctly. If the low-level driver just blindly enables IO cycles by > > > writing to the PCI_COMMAND register, that device may come up in an invalid > > > state, and mess up the whole system. The driver simply does not KNOW > > > enough. It doesn't know where other devices are, and it _shouldn't_ know. > > > > How do you want this to happen ? Could you elaborate. > > It's really easy. > > Call "pci_enable_device()". > > What's so hard about that? This function delegates too much as a whole to the PCI generic layer, IMO. Imagine that for sanity I want to allocate all the device resources, but only _enable_ part of device features (for example only memory transactions). Imagine some special handling to be necessary due to some chip bug. > You don't seem to realize, but it's entirely possible to have a setup > where some device CANNOT be allocated it's IO region. The BIOS may have > left the device disabled on purpose, simply because there wasn't enough > free space in the memory map to enable the device anywhere. PCI specs said corresponding BAR must be set to ZERO, here. > You can't just have the device driver enable such a device. It _has_ to > ask the PCI layer to do it for it - because the PCI layer is the only one > that can figure out that "Oh, damn, this machine has 3GB of memory, and 4 > video cards that want a 256MB aperture each, and we don't have any place > to map this card any more". I want to say the generic layer "What to do" in some more fine-grained way than just a single verb, at least. I may accept to delegate it some "How to do it". > No ifs, why's or buts. A driver that just enables the IO windows is a > buggy driver. In PCI, you donnot enable windows, but you enable/disable devices to generate and/or respond to transactions. OTOH, if you look at all the bits in the COMMAND register, you will see that some other features are also to be addressed by the enabling/disabling kernel interface. > > > In contrast, the general PCI layer _does_ know. It keeps track of > > > resources, makes sure that different cards do not have overlapping address > > > ranges, knows about PCI bridges (a card behind a PCI bridge can only be > > > enabled after the _bridge_ has been enabled and can only be mapped in the > > > region that the bridge maps). > > > > Yes, it is expected to do its work (e.g. assigning ressources to all > > agents on the BUS hierachy). > > Right. > > And sometimes it CANNOT. > > End of story. > > Linus Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
Hi! > It is a real issue of failure in 2.2, and it would be useful if the PPC > folks want to use Ultra-ATA cards. For 2.4, making the IDE driver call pci_enable_device() and modifying the PPC PCI code to fix up whatever is needed there. For 2.2, it's probably better to leave things as they are and just ask PPC guys for adding a special fixup to their code. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Q: How to start hacking Linux? A: vi /boot/vmlinuz" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Preallocated skb's?
On Fri, 15 Sep 2000, Bogdan Costescu wrote: > On Fri, 15 Sep 2000, jamal wrote: > > You use the period(5-10micros), while waiting > > for full packet arrival, to make the route decision (lookup etc). > > i.e this will allow for a better FF; it will not offload things. > > Just that you span several layers by doing this, it's not driver specific > anymore. Many chips have some sort of early-Rx feature, but it's still a bad idea for the many reasons I've pointed out before. An additional reason not use early-Rx is that chips such as the 3c905C are most efficient at using the PCI bus when transfering a whole packet in a single PCI burst (plus two smaller bursts initially reading and later writing the descriptor). Using an early-Rx interrupt scheme means using multiple smaller bursts. The early-Rx scheme worked well on the ISA bus, where transfers were slow and not bursting. Also note: it is possible to drop an Rx packet after the early Rx interrupt. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Beowulf-II Cluster Distribution Annapolis MD 21403 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: nfs v3 (fwd)
I hate to say it, but NFS on Linux has been the worst thing I've every had to deal with since SLS was the only person on the hill. Every now and then I give it a go and try to read through the v2/v3/v29384 tangle of packages and documentation for building/using. Nobody has a usable set of documentation for "current" NFS. If you want NFS, use somebodies pre-cooked design. -d "Albert D. Cahalan" wrote: > For the benefit of some disbelievers, here we go again, just today. > Somebody, not be be named, was caught jumping ship due to NFS. > > - > >>> What version of nfs supproted in last stable FreeBSD ? > >>> The v2 only or v3 too? > >> > >> What an odd question to ask... let me guess, Linux 2.2.xx is giving > >> you trouble and you don't know that a fix is available? > > > > :) yes, sure. You are right. > > Do you know some way to solve it ? > - > > Unfortunately, not everybody gets help like this person did. > The people posting in public are the tip of an iceberg. -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: [PATCH *] VM patch for 2.4.0-test8
Jamie Lokier wrote: > Martin Josefsson wrote: > > I've been trying to get my machine to swap but that seems hard with this > > new patch :) I have 0kB of swap used after 8h uptime, and I have been > > compiling, moving files between partitions and running md5sum on files > > (that was a big problem before, everything ended up on the active list and > > the swapping started and brought my machine down to a crawl) > > No preemptive page-outs? > > 0kB swap means if you suddenly need a lot of memory, inactive > application pages have to be written to disk first. There are always > inactive application pages. > > Maybe the stats are inaccurate. Perhaps, but I run most of my machines without swap. They are between 64 and 256M. Servers are pretty constant in their mem usage, I use about 75%. The workstations sometimes run down to a few megs free (read 'using netscape') and I then turn on a swapfile. But all in all they generally do dandy without swap for days on some, months on others. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
PROBLEM: ds.o fails to properly enable CardBus card (2.4.0t8)
Hi I have a Xircom RealPort card which currently is useless under Linux on my laptop. I have tried the kernel pcmcia code and David's standalone package. After insmod'ing ds.o, I get: cs: cb_alloc(bus 4): vendor 0x115d, device 0x0003 PCI: Failed to allocate resource 1 for PCI device 115d:0003 PCI: Failed to allocate resource 2 for PCI device 115d:0003 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 04:00.0 ( -> 0003) PCI: Failed to allocate resource 1 for PCI device 115d:0103 PCI: Failed to allocate resource 2 for PCI device 115d:0103 PCI: Failed to allocate resource 6 for PCI device 115d:0103 PCI: Enabling device 04:00.1 ( -> 0003) I also note the following output from the kernel: PCI: PCI BIOS revision 2.10 entry at 0xfc0ee, last bus=1 So: the PCI code says that the last bus is '1', but my CardBus bus #4. Is this expected? I also notice that if I insmod/rmmod ds.o multiple times, I will get multiple entries for the devices on the card in the 'lspci' output: 04:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) 04:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) 04:00.1 VGA compatible controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) 04:00.1 VGA compatible controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) Hardware: Dell CPiA366 (tested bios rev. A01/A05/A09), Xircom RealPort RBEM56G-100. Software: plain 2.4.0-test8, gcc 2.95.2. The following should illustrate the problem in full. dagblap:~# lsmod Module Size Used by dagblap:~# lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:03.0 CardBus bridge: Texas Instruments PCI1225 (rev 01) 00:03.1 CardBus bridge: Texas Instruments PCI1225 (rev 01) 00:07.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:0d.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] 01:00.0 VGA compatible controller: Neomagic Corporation [MagicMedia 256AV] (rev 20) 01:00.1 Multimedia audio controller: Neomagic Corporation [MagicMedia 256AV Audio] (rev 20) dagblap:~# insmod pcmcia_core Using /lib/modules/2.4.0-test8/kernel/drivers/pcmcia/pcmcia_core.o dagblap:~# insmod yenta_socket Using /lib/modules/2.4.0-test8/kernel/drivers/pcmcia/yenta_socket.o dagblap:~# insmod ds Using /lib/modules/2.4.0-test8/kernel/drivers/pcmcia/ds.o dagblap:~# dmesg Linux version 2.4.0-test8 (root@dagblap) (gcc version 2.95.2 19991024 (release)) #4 Fri Sep 15 17:05: 21 CEST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 05ef @ 0010 (usable) BIOS-e820: 0001 @ 05ff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 24560 zone(0): 4096 pages. zone(1): 20464 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=test8d ro root=/dev/discs/disc0/part5 Initializing CPU#0 Detected 363963654 Hz processor. Console: colour dummy device 80x25 Calibrating delay loop... 725.81 BogoMIPS Memory: 94284k/98240k available (1487k kernel code, 3568k reserved, 104k data, 196k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Intel Mobile Pentium II stepping 0a Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfc0ee, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router default [8086/1234] at 00:07.0 Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 i2c-core.o: i2c core module i2c-dev.o: i2c /dev entries driver module i2c-core.o: driver i2c-dev dummy driver registered. i2c-algo-bit.o: i2c bit algorithm module vesafb: framebuffer at 0xfb00, mapped to 0xc680, size 2432k vesafb: mode is 1024x768x8, linelength=1024, pages=2 vesafb: protected mode interface info at c000:aea0 vesafb: scrolling: redraw Console: switching to colour frame buffer device 128x48 fb0: VESA VGA frame
Re: [bug report] pcmcia in kernel 2.4.0-test8
Alessandro Suardi wrote: > Kernel pcmcia code works fine with 2.4.0-test8 and my Xircom RBEM56G100TX, > in fact I am writing from my laptop connected through it. See lsmod output > and relevant part of .config. > > [asuardi@princess asuardi]$ lsmod > Module Size Used by > serial_cb 1456 1 > xircom_tulip_cb30168 1 > cb_enabler 2536 2 [serial_cb] > ds 6540 2 [cb_enabler] > yenta_socket9932 4 > pcmcia_core39264 0 [cb_enabler ds yenta_socket] > sb 1712 1 (autoclean) > sb_lib 33660 0 (autoclean) [sb] > uart401 6436 0 (autoclean) [sb_lib] > [asuardi@princess asuardi]$ For a good many people, yes it does work. For this hardware it doesn't work. pcmcia_core and yenta_socket are the only two modules I can load, and once loaded they can't be unloaded. Trying to rmmod yenta_socket yeilds a segfault and the module remains in a (deleted) state. The kernel pcmcia can't get the sockets set up correctly. It used to work; on 1 socket only and randomly blew up the kernel. The other socket hung the interrupts. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Gérard Roudier wrote: > > > Just as an example: imagine that the IO windows haven't been set up > > correctly. If the low-level driver just blindly enables IO cycles by > > writing to the PCI_COMMAND register, that device may come up in an invalid > > state, and mess up the whole system. The driver simply does not KNOW > > enough. It doesn't know where other devices are, and it _shouldn't_ know. > > How do you want this to happen ? Could you elaborate. It's really easy. Call "pci_enable_device()". What's so hard about that? You don't seem to realize, but it's entirely possible to have a setup where some device CANNOT be allocated it's IO region. The BIOS may have left the device disabled on purpose, simply because there wasn't enough free space in the memory map to enable the device anywhere. You can't just have the device driver enable such a device. It _has_ to ask the PCI layer to do it for it - because the PCI layer is the only one that can figure out that "Oh, damn, this machine has 3GB of memory, and 4 video cards that want a 256MB aperture each, and we don't have any place to map this card any more". No ifs, why's or buts. A driver that just enables the IO windows is a buggy driver. > > In contrast, the general PCI layer _does_ know. It keeps track of > > resources, makes sure that different cards do not have overlapping address > > ranges, knows about PCI bridges (a card behind a PCI bridge can only be > > enabled after the _bridge_ has been enabled and can only be mapped in the > > region that the bridge maps). > > Yes, it is expected to do its work (e.g. assigning ressources to all > agents on the BUS hierachy). Right. And sometimes it CANNOT. End of story. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
In article <[EMAIL PROTECTED]>, David Howells <[EMAIL PROTECTED]> wrote: > >Oliver Neukum <[EMAIL PROTECTED]> wrote: >> > (3) Even if it was... just filling in the syscall slot from a module means >> > that it is possible for the module to be unloaded whilst the syscall is in >> > use. Note that all this is not the problem. The problem is that dynamic system calls are not going to happen. Why? License issues. I will not allow system calls to be added from modules. Because I do not think that adding a system call is a valid thing for a module to do. It's that easy. It's the old thing about "hooks". You must not sidestep the GPL by just putting a hook in place. And dynamic system calls are the ultimate hook. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Rik's t8sched patch breaks pcmcia
[my MTA wasn't very happy with that message, so I'm starting fresh] Hi Joe, My scheduler patch changes the task_struct a little bit. That means you'll have to recompile your modules before things will work... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with bluesmoke.c in 2.2.17
Hi! > e other day I got the patch for 2.2.17 and after just over a day of normal > > operation, while my sister was playing kpat (KDE solitaire) yesterday > > afternoon, X died and dropped her out to the console. > > After she told me about it later on I found this at the bottom of my dmesg: > > > > CPU 0: Machine Check Exception: 0004<0>Bank 3: b2080a01general >protection fault: > > Ok I print low,high which was wrong - it should read 0004 > which is 'machine check in progress' > > So its a real machinme check > > > CPU:0 > > EIP:0010:[] > > Oh beautiful. This is wonderful. I've been hoping for a chance to test the MCE > code. Ok you might not agree 8) > > Right there is missing \n I'll go fix but the rest of it says > > b2- register valid, uncorrected error, error enabled > 0008 - model specific data > 0a01 - memory access, > generic error > l1 cache > processor responding to request Does that mean that processor itself detected that its L1 cache s failing and was honest enough to tell the OS? -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible elevator performance in kernel 2.4.0-test8
In article <[EMAIL PROTECTED]>, Ingo Molnar <[EMAIL PROTECTED]> wrote: > >i'm seeing similar problems. I think these problems started when the >elevator was rewritten, i believe it broke the proper unplugging of IO >devices. Does your performance problem get fixed by the attached >workaround? If this helps, that implies that somebody is doing a (critical) IO request, without ever actually asking for the request to be _started_. That sounds like a bug, and the patch looks like band-aid. Where do we end up scheduling without starting the disk IO? I'd rather add the disk schedule to _that_ place, instead of adding it to every re-schedule event. (For example, on a multi-CPU system it should _not_ be the case that one CPU scheduling frequently should cause IO performance to go down - yet your patch will do exactly that). Could you make it print out a backtrace instead when this happens (make it do it for the first few times, so as not to flood your console forever if it ends up being common..) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Linus Torvalds wrote: > On Fri, 15 Sep 2000, Richard B. Johnson wrote: > > > > The PCI Specification states, in part, that either the BIOS or the > > driver has to enable the device. So, many drivers find that the device > > has not been enabled. This is normal and necessary because many/most > > PCI hardware had better not be enabled until an ISR is in-place. > > But that's why we have the "pci_enable_device()" function. And that's why > we have the generic PCI setup functionality that finds and enables devices > at the right addresses. > > DO NOT USE ANY LOCAL HACKS. Use the proper function. Don't go mucking > around with random configuration state information: enabling a device > involves a lot more than just writing stuff to configuration ports. Things > like making sure the interrupt routing on the motherboard has been > enabled, etc. Things that the driver does not know about, and should not > even _try_ to understand. > > The PCI layer should be used to handle generic PCI issues. A low-level > driver should _never_ try to handle resource allocation and enabling in > hardware. Disagreed about `enabling'. > Just as an example: imagine that the IO windows haven't been set up > correctly. If the low-level driver just blindly enables IO cycles by > writing to the PCI_COMMAND register, that device may come up in an invalid > state, and mess up the whole system. The driver simply does not KNOW > enough. It doesn't know where other devices are, and it _shouldn't_ know. How do you want this to happen ? Could you elaborate. > In contrast, the general PCI layer _does_ know. It keeps track of > resources, makes sure that different cards do not have overlapping address > ranges, knows about PCI bridges (a card behind a PCI bridge can only be > enabled after the _bridge_ has been enabled and can only be mapped in the > region that the bridge maps). Yes, it is expected to do its work (e.g. assigning ressources to all agents on the BUS hierachy). > To make a long story short: a driver that touches the PCI_COMMAND or other > generic PCI registers by hand is a _buggy_ driver. It's a sure recipe for > disaster. I disagree 100% with this statement. The genericity of PCI configuration is only here to facilitate configuration of all the devices on a BUS hierarchy. Indeed a PCI device driver must not tamper the resources the device got from the generic PCI layer. But it is expected to know better about the PCI devices it supports that any generic PCI layer. Not everything are generic in PCI. What about device bugs, for example? About bridges, part of their configuration can be handled generically, but not everything. The generic PCI layer that deals with bridges have to know bridge quirks and special features as you know. In some way, the PCI generic layer acts as PCI device drivers for the bridges. Configuring and enabling are 2 different issues. Configuring has been designed to be generic in PCI but the `enabling' should be performed by the entity that knows the best about the real device, thus the PCI device driver. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
several lockups and performance
Hi, 2.4.0-test8, 2.4.0-test7, 2.4.0-test5 1. bridge. If to set bridge addr on C level after bridge is created, but before any interfaces are ever attached to it, it oopses. The box I am doing it is quite embedded and I am too lazy to set up any serial line debugging or nfs root, so I could say about it at the moment, that it occurs somewhere in bridge code around kmallocing. 2. 3c509 isapnp 3c509 goes up straight, but, with cards configured pnp-mode, with 4 cards, there will be a lockup after the second one. It is probably the generic problem about 3c509 no tolerating foreign interrupts. weird is that sysreq works, but with about 30 sec latency. No oops onscreen. Looks like being in cycle somewhere. P75, 16MB memory, Compaq, PCnet32 onboard, 4x3c509B cards 3. SMP ACPI ? this is on server box. Dont know where it is, but once a day or so, after being away from computer, it wont be happy when I touch it again. Never happened while sitting there, allways when coming back. Sometimes X locks up, but most usually locks whole box. SysReq works, but it allways happnes on graphics console after display coming on and I have typed some letters into X screensaver lock password dialog. 4. performance problem: 10Mbit bridge with very minimalistic kernel is 20% slower with 8MB ram as compared to 16MB ram. Other interesting feature is, that it is 100% slower at start and after some minutes of run, comes to 20%... ultimately weird. kernel is 450kB compressed, has vfat as root fs, and whatever else possibly disabled. TCP is supported but real minimalistic. elmer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: usb-uhci forgets to destroy kmem entries
> > +#ifdef DEBUG_SLAB
> > + if (retval < 0 ) {
> > + if(kmem_cache_destroy(uhci_desc_kmem))
>
> Why only #ifdef DEBUG_SLAB?
> AFAICS the driver should always destroy it's slab cache.
>
> Please cc, I'm not subscribed to linux-kernel.
(why not? :)
> --
> Manfred
This driver only uses slab caches when it's debugging.
DEBUG & SLAB go together.
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
In article <[EMAIL PROTECTED]>, Eli Carter <[EMAIL PROTECTED]> wrote: >Mitchell Blank Jr wrote: >> Daniel Quinlan wrote: >> > "Version" - the base kernel version. For example, "2.4.0-test8-pre1". >> > The web page will list valid version strings. >> Ideally this should be overridable for patches marked experimental, since >> they might be to some modified kernel. Of course you wouldn't do an >> test for applyability :-) > >Yes you can. Use the "Requires" identifier to add all the previous >patches first. But if the patch for the prerequisite modification isn't >available, what is the point of submitting the patch? If both patches are submitted at near the same time, the prerequisite patch may not arrive until after its dependents; in that case, you'd want the patch tracking system to hold on to the dependents until the prerequisite showed up. Consider the following scenario: developer A makes a patch P. developer A sends a copy of P to the patch tracking system. developer A CC's a copy of P to developer B in the same email. the copy of P for the patch tracking system enters a Microsoft Exchange email server during a Visual Basic Scripting Host virus incident, and is delayed by 48 hours. developer B fixes a bug in P, making patch Q. developer B submits Q to patch tracking system with "Requires: P" (assuming B has some identifier for P; see below for ideas on how to do this). the patch tracking system receives Q from B. To cope with the scenario outlined above, in addition to a numeric ID assigned by the patch server, the server should support reference to a patch by the MD5 hash of the patch text, or by message-IDs in email headers when patches are submitted. When the patch server can unambiguously translate one of those into a locally unique ID for the patch, it should do so, but leave the original specification in its internal database so that the patch can be meaningfully exported again. I'd recommend using the MD5 hash (ok, SHA-1 if you insist) of the patch text (i.e. the stuff you actually input to 'patch') as the actual patch identifier, and make the other ID forms search queries that ultimately resolve the MD5 hash. This has the advantage of allowing for a single globally unique identifier for all patches even if there are multiple kernel patch servers operated by different groups. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: nfs v3 (fwd)
For the benefit of some disbelievers, here we go again, just today. Somebody, not be be named, was caught jumping ship due to NFS. - >>> What version of nfs supproted in last stable FreeBSD ? >>> The v2 only or v3 too? >> >> What an odd question to ask... let me guess, Linux 2.2.xx is giving >> you trouble and you don't know that a fix is available? > > :) yes, sure. You are right. > Do you know some way to solve it ? - Unfortunately, not everybody gets help like this person did. The people posting in public are the tip of an iceberg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: usb-uhci forgets to destroy kmem entries
>
> +#ifdef DEBUG_SLAB
> + if (retval < 0 ) {
> + if(kmem_cache_destroy(uhci_desc_kmem))
Why only #ifdef DEBUG_SLAB?
AFAICS the driver should always destroy it's slab cache.
Please cc, I'm not subscribed to linux-kernel.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
On Fri, Sep 15, 2000 at 09:08:25PM -0400, Giuliano Pochini wrote: > Which is tightly dependent on the way we insert new rqs. Sure the implementation would differ in function of the way we order the requests during inserction, but the conceptual algorithm of the latency control could remain the same even if we'll sligtly change the ordering algorithm. The reason the implementation would differ is because they are implemented together to browse the queue the less times possible. > Rqs are added according to the IN_ORDER() condition which enforces ascending > ordering. What does CSCAN mean ? CSCAN means Cyclic scan. It enforces ascending order and when it reaches the last cylinder it causes a large seek to the head. > [..] When we insert 15 the list becomes 12 13 14 1 2 3 15. You're right. Infact the only reason we need the latency control stuff is that 14 have to become a barrier eventually (and 15 have to become a barrier eventually as well) if we want them to be served by the lowlevel driver otherwise they could be passed for way too long time (just the time to write some Tera of data to disk) by requests with lower blocknr. This was the elevator latency bugfix. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.17 doesnt build on sparc64 with CONFIG_IP_PNP
Hi, current 2.2.17 sparc64 kernel doesnt build with CONFIG_IP_PNP enabled make[2]: Entering directory `/usr/src/linux/arch/sparc64/kernel' sparc64-linux-gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare -c -o setup.o setup.c setup.c: In function `setup_arch': setup.c:553: `ic_set_manually' undeclared (first use in this function) setup.c:553: (Each undeclared identifier is reported only once setup.c:553: for each function it appears in.) make[2]: *** [setup.o] Error 1 make[2]: Leaving directory `/usr/src/linux/arch/sparc64/kernel' make[1]: *** [_dir_arch/sparc64/kernel] Error 2 make[1]: Leaving directory `/usr/src/linux' make: *** [stamp-build] Error 2 Flo -- Florian Lohoff [EMAIL PROTECTED] +49-5201-669912 "Write only memory - Oops. Time for my medication again ..." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH *] VM patch for 2.4.0-test8
Martin Josefsson wrote: > I've been trying to get my machine to swap but that seems hard with this > new patch :) I have 0kB of swap used after 8h uptime, and I have been > compiling, moving files between partitions and running md5sum on files > (that was a big problem before, everything ended up on the active list and > the swapping started and brought my machine down to a crawl) No preemptive page-outs? 0kB swap means if you suddenly need a lot of memory, inactive application pages have to be written to disk first. There are always inactive application pages. Maybe the stats are inaccurate. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
> >It's a good way to avoid stalls, but IMHO I thing the elevator should > > Here you're talking about the latency control logic. Which is tightly dependent on the way we insert new rqs. > >not work this way. The main problem is that it doesn't minimize head > >movement. For example, when comes a request for a sector at the > > The algorithm that control the latency and the one that enforce the > ordering are two separate things. > > For example in 2.2.15 there's only the latter (2.2.15 was missing a > latency control mechanism). > > >beginning of the disk it goes to the beginning of the queue (it's > >ordered) so it will be serviced before other rqs (it picks up rqs from > >the head). This way the higher is the block number, more likely that > >rq will wait a lot. > > We're not using a SCAN ordering algorithm it's instead a CSCAN. The queue > can be for istance: > > 12 13 14 1 2 3 > > Now insert 15 (assume 15 is the last sector of the disk): > > 12 13 14 15 1 2 3 Rqs are added according to the IN_ORDER() condition which enforces ascending ordering. What does CSCAN mean ? ie, if the queue initially is 1 2 3 it will become 1 2 3 14. If it's 12 13 14 and we insert 2: 2 12 13 14. So your example can happen only if the list is 12 13 14 and "14" is the latency barrier. When we insert 15 the list becomes 12 13 14 1 2 3 15. Am I missing something ? > PS. Thanks for having read and understood the internals of the 2.4.x > elevator before posting your comments, it simplifies very much the > communication. I had to study it while hunting for the no-merge bug :) Bye. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test8 - lockdsvc: Invalid argument
Hi, First, I'm sorry but I cannot afford the huge traffic of messages from joining the list. Can you please CC me directly with any response? TIA. I upgraded from test7 to test8 via the patch file and I'm now getting the failure... rpc.lockd: lockdsvc: Invalid argument I have tried moving to the latest knfsd-lockd stuff to no avail. How do I fix this error? There doesn't appear to be anything in the Changes on this. Thanks, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4-test8: Oops, FS damage on SCSI DVD-RAM
There, I've summoned the courage to post it ;-) I have a Toshiba 1101 DVD-RAM drive attached to a Symbios 53C810a SCSI card. I have a cartridge formatted by Windows to FAT-16 with 64K clusters. It has never worked in 2.4-test (I got the drive on test-6) however it works perfectly using the 2.2 series kernels. The DVD-RAM drive is in two-LUN configuration: using single-LUN doesn't seem to make any odds. Before I trusted anything to the DVD-RAM drive I wanted to be sure it worked, so I copied 410MB of .RAR archives to the disk. At first I just got CRC errors and once a trashed FS on the cartridge (it was Ext-2 formatted at the time) , but since installing test-7 I get a kernel Oops when trying to decompress an archive on the cart (or even read it with less!) The test cart is currently formatted by Windows to FAT-16 with 64k clusters. I am not on the mailing list so if you could CC replies to me directly that would be great. [OOPS] ksymoops 2.3.4 on i586 2.4.0-test8. Options used -v vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test8/ (default) -m /usr/src/linux/System.map (default) Unable to handle kernel NULL pointer dereference at virtual address *pde = Oops: CPU:0 EIP:0010:[ppp_cleanup+0/4] EFLAGS: 00010286 eax: ebx: c4427f00 ecx: 0003 edx: c4427f00 esi: ffea edi: ebp: 0001 esp: c40eff88 ds: 0018 es: 0018 ss: 0018 Process rar (pid: 1247, stackpage=c40ef000) Stack: c014f918 c4427f00 40101000 0001 c4427f20 c012ce55 c4427f00 40101000 0001 c4427f20 c40ee000 bffeb9a4 080afb38 bffeab8c c010a623 0003 40101000 0001 bffeb9a4 080afb38 bffeab8c 0003 002b 002b Call Trace: [fat_notify_change+80/248] [get_hardblocksize+25/36] [ret_from_sys_call+3/18] Code: Bad EIP value. Using defaults from ksymoops -t elf32-i386 -a i386 [Software versions] -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux seaharrier.it-he.org 2.4.0-test8 #8 Sat Sep 9 17:01:41 BST 2000 i586 unknown Kernel modules 2.3.15 Gnu C 2.95.2 Binutils 2.9.5.0.16 Linux C Library2.1.2 Dynamic linker ldd (GNU libc) 2.1.2 Procps 2.0.6 Mount 2.9y Net-tools 1.53 Console-tools 0.2.2 Sh-utils 2.0 Modules Loaded mga [CPU] processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 9 model name : AMD-K6(tm) 3D+ Processor stepping: 1 cpu MHz : 400.913894 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow bogomips: 799.54 [MODULES] mga 100976 1 [IOMEM] -0009fbff : System RAM 0009fc00-0009 : System RAM 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-05fe : System RAM 0010-002f0157 : Kernel code 002f0158-00317343 : Kernel data 05ff-05ff2fff : ACPI Non-volatile Storage 05ff3000-05ff : ACPI Tables e000-e3ff : PCI Bus #01 e000-e0003fff : Matrox Graphics, Inc. MGA G400 AGP e000-e0003fff : matroxfb MMIO e100-e17f : Matrox Graphics, Inc. MGA G400 AGP e400-e5ff : VIA Technologies, Inc. VT82C597 [Apollo VP3] e600-e7ff : PCI Bus #01 e600-e7ff : Matrox Graphics, Inc. MGA G400 AGP e600-e7ff : matroxfb FB e900-e903 : Aureal Semiconductor Vortex 2 e904-e90400ff : Symbios Logic Inc. (formerly NCR) 53c810 e9041000-e90410ff : Lite-On Communications Inc LNE100TX e9041000-e90410ff : eth0 - : reserved [IOPORTS] -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 0213-0213 : isapnp read 0220-022f : soundblaster 02f8-02ff : serial(auto) 0330-0333 : MPU-401 UART 0378-037a : parport0 037b-037f : parport0 03c0-03df : vga+ 03c0-03df : matrox 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0778-077a : parport0 0a79-0a79 : isapnp write 0cf8-0cff : PCI conf1 5000-50ff : VIA Technologies, Inc. VT82C586B ACPI d000-d00f : VIA Technologies, Inc. Bus Master IDE d800-d8ff : Symbios Logic Inc. (formerly NCR) 53c810 d800-d87f : sym53c8xx dc00-dcff : Lite-On Communications Inc LNE100TX dc00-dcff : eth0 e000-e007 : Aureal Semiconductor Vortex 2 e400-e407 : Aureal Semiconductor Vortex 2 [PCI] 00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR-
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Alan Cox wrote: > > The PCI Specification states, in part, that either the BIOS or the > > driver has to enable the device. So, many drivers find that the device > > has not been enabled. This is normal and necessary because many/most > > PCI hardware had better not be enabled until an ISR is in-place. > > The Linux 2.4 kernel API means that you must call > > pci_enable_device(dev) > > which also knows about architecture specific magic too > > Alan > Okay. So, in effect, PCI is no longer a bus that drivers have to know about, but a logical device. This is good. The stuff I've been working on (2.2.+) doesn't have this capability. It will be good when we have a stable version (err non-broken) of 2.4 for me to port my drivers to. I just conldn't keep up with the continual changes and sorta gave up for the time being. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8 breaks ide-scsi
On Fri, 15 Sep 2000, Samuli Kaski wrote: > Another thing is that either the kernel or the new modutils break > RedHat's mixer-setting/sound detection scripts. (I have a es1371 based > soundcard) However once the sound modules are manually inserted & mixer > settings loaded, sound works just fine. I'm not sure but I think I saw > this already with -test7. I take it you renamed /etc/conf.modules to /etc/modules.conf .. if so replace all instances of conf.modules to modules.conf in /etc/rc.d/rc.sysinit. > > The kernel also breaks lmsensors but that's probably yet another > story... > http://www.haque.net/software/patches/lm_sensors-2.5.2+2.4.0-test8-pre2.diff.gz -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8
Title: Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8 Hi, I've been having kernel oopses with the 2.4.0-test series and am including ksymoops processed output from both test4 and test5 kernels. The same oops happens in later kernels too (Tested with test6, test7 and test8). The scenario is this: I have an incoming UDP stream at 1mbit. The router marks packets in this stream, according to port ranges, with 3 (or any # of) marks (via iptables v1.1.1). iproute2 builds new routing tables based on these marks, and mplsadm, with the tc patch, is called to build LSPs using these routing tables. Finally, the 3 egress LSPs are rate limited using tc (employing cbq classes) to a value less than the ingress rate (ie: I limited each LSP to 200kbit, for an aggregate egress output rate of 600kbit). When I start the traffic flowing from our generator, the box panics and freezes quite solidly. Policing via filters also crashes the box. If I move the egress rate limiting function to another box, it works okay. I've also noted that the crash only occurs if I throttle the traffic flow to an egress rate which is less than the ingress rate (ie: ingress flow at 1mbit and egress flow at 1mbit works fine. If the egress rate is reduced, boom!) I copied down the oopses and ran 'ksymoops < oops.txt > oops_proc.txt' and pasted them here. The first is from kernel 2.4.0-test4 and the second from 2.4.0-test5. NEW: Here's the funny part. In mm/slab.c, the function kmem_cache_grow() contains a check as follows: /* * The test for missing atomic flag is performed here, rather than * the more obvious place, simply to reduce the critical path length * in kmem_cache_alloc(). If a caller is seriously mis-behaving they * will eventually be caught here (where it matters). */ /* Commented out Sep 15 since it was crashing my router. */ /* if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC) BUG(); */ This is the check that fails and causes the oops. Not understanding what is actually being checked, and not knowing the repercussions of tampering with it, I commented out the check, recompiled and reran the test. I understand that this is not really a fix (it's more akin to just turning my head and pretending that the problem doesn't exist, but... it seems to work.) The result: Great joy and much celebration! I'm throwing 7.2mbps at the box, limiting the rate to 900kbit aggregate throughput and it's working! The numbers I'm getting also seem to jive with anticipated results. Cheers! Jon ksymoops 0.7c on i686 2.4.0-test4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test4/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. invalid operand: CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 001b ebx: c7ffd0c0 ecx: edx: 0082 esi: 0246 edi: c7ffd0c0 ebp: 0007 esp: c024fe70 ds: 0018 es: 0018 ss: 0018 Process swapper (pid:0, stackpage=c024f000) Stack: c01fb794 c01fb834 0412 c7ffd0c0 0247 0007 c024fed4 c7d1602e c0127aaf c7ffd0c0 0007 c7d170e0 c7d1602e c01eb196 0008 0007 c7d170e0 c7d1602e c7f8be00 c01b6aaf c7d170e0 Call trace: [][][][][][][] [][][][][][][][] [][][][][][][][] Code: 0f 0b 83 c4 0c c7 44 24 10 01 00 00 00 89 ee 83 e6 07 b8 03 >>EIP; c01277fd <= Trace; c01fb794 Trace; c01fb834 Trace; c0127aaf Trace; c01eb196 Trace; c01b6aaf Trace; c01b6c6f Trace; c01b6a84 Trace; c019b1c4 Trace; c01b6936 Trace; c01b6a84 Trace; c019efe3 Trace; c011b17f Trace; c010b8ee Trace; c01087e0 Trace; c01087e0 Trace; c010a518 Trace; c01087e0 Trace; c01087e0 Trace; c0100018 Trace; c0108803 Trace; c0108864 Trace; c0105000 Trace; c0100192 Code; c01277fd <_EIP>: Code; c01277fd <= 0: 0f 0b ud2a <= Code; c01277ff 2: 83 c4 0c add $0xc,%esp Code; c0127802 5: c7 44 24 10 01 00 00 movl $0x1,0x10(%esp,1) Code; c0127809 c: 00 Code; c012780a d: 89 ee mov %ebp,%esi Code; c012780c f: 83 e6 07 and $0x7,%esi Code; c012780f 12: b8 03 00 00 00 mov $0x3,%eax Aiee, killing interrupt handler Kernel panic: Attempted to kill the
strange nic behavior
I have a nic here which acts somehow strange. When I load the ne.o module while connected to the hub then link goes down. When pull the connector from the hub and load the module and then plug it back in, it works fine. I somehow suspect that the nic selects the wrong media. How can I force it to use the rj45 connector and not the bnc connector? Regards Martin -- Happiness is twin floppies. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting new kernel from running kernel
Frank Smith wrote: > > Hi, > > I'm trying to figure out a way to immediately boot a > new kernel from within a running system. I do not > care about gracefully shutting down the first kernel.. > once I decide to run the new kernel, I'll abandon the > first. Take a look at http://www.scyld.com/software/monte.html -- David N. Lombard MSC.Software - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
> The PCI Specification states, in part, that either the BIOS or the > driver has to enable the device. So, many drivers find that the device > has not been enabled. This is normal and necessary because many/most > PCI hardware had better not be enabled until an ISR is in-place. The Linux 2.4 kernel API means that you must call pci_enable_device(dev) which also knows about architecture specific magic too Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OOPS] in 2.4.0-test8 occuring in low memory machines
Sorry I can't be more explicit in checking this out, still working my way through definitive situations where these occur, but seem to be in low memory machines, running initrd.gz minix filesystems.. I started gettting OOPS soon after running a patch to rd.c to allow for encrypted initrd.gz, and I thought it was something to do with the patch, but it seems this is a deeper issue, because we are now getting it even when using an unencrypted initrd.gz. Only seems to happen on Pentium/486 class machines with 8-16 MG RAM Also, we are running a minix file system. First OOPS occured after gunzip routine completed, while using the encrypted initrd.gz.. (Unencrypted OOPS below) Not a master of ksymoops, but included it incase it helps. Unable to handle kernel paging request at virtual address 8140c35b printing eip: c015e483 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010293 eax: 8140c357 ebx: 8140c35f ecx: c10952d0 edx: c10951d0 esi: 0042 edi: ebp: 000a esp: c1ffd824 ds: 0018es: 0018ss: 0018 Process swapper (pid: 1, stackpage=c1ffd000) Stack: 0008 c015f1e4 c1f04008 0005 001d c1ffdd8c c1ffd874 c1ffd870 c1ffd86c 001e 011e 0012 013c 007f c1f19408 0006 c1f04008 0009 0005 0006 0007 0007 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 8b 58 04 50 e8 44 78 05 00 89 d8 83 c4 04 85 c0 75 eb 31 c0 Kernel panic: Attempted to kill init! >>EIP; c015e483<= Trace; c015f1e4 Trace; c015f2e9 Trace; f0708b1f Trace; c015f366 Trace; f0708b1f Trace; c015f753 Trace; c011a28d Trace; c0100018 Trace; c01070e7 Trace; c0107518 Code; c015e483 <_EIP>: Code; c015e483<= 0: 8b 58 04 movl 0x4(%eax),%ebx <= Code; c015e486 3: 50pushl %eax Code; c015e487 4: e8 44 78 05 00call 5784d <_EIP+0x5784d> c01b5cd0 Code; c015e48c 9: 89 d8 movl %ebx,%eax Code; c015e48e b: 83 c4 04 addl $0x4,%esp Code; c015e491 e: 85 c0 testl %eax,%eax Code; c015e493 10: 75 eb jnefffd <_EIP+0xfffd> c015e480 Code; c015e495 12: 31 c0 xorl %eax,%eax Latest OOPS discovered Unable to handle kernel paging request at virtual address c839a5b4 printing eip: c8124c70 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010282 eax: ebx: c839a5b0 ecx: 400ec000 edx: c020f360 esi: 400e8000 edi: c020f360 ebp: 0004 esp: c0097f90 ds: 0018es: 0018ss: 0018 Process kswapd (pid: 2, stackpage=c0097000) Stack: c020f360 0015 c0124d51 c020f360 0004 0010 0027 0008 0028 0054 c0124f0c 0028 0004 00010f00 0003 0001 0008e000 c0125038 0004 c009bf98 Call Trace: [] [] [] [] Code: 8b 73 04 55 56 53 57 e8 24 fe ff ff 83 c4 10 85 c0 75 1d 8b ksymoops output Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: ebx: c839a5b0 ecx: 400ec000 edx: c020f360 esi: 400e8000 edi: c020f360 ebp: 0004 esp: c0097f90 ds: 0018es: 0018 ss: 0018 Process kswapd (pid: 2, stackpage=c0097000) Stack: c020f360 0015 c0124d51 c020f360 0004 0010 0027 0008 0028 0054 c0124f0c 0028 0004 00010f00 0003 0001 0008e000 c0125038 0004 c009bf98 Call Trace: [] [] [] [] Code: 8b 73 04 55 56 53 57 e8 24 fe ff ff 83 c4 10 85 c0 75 1d 8b >>EIP; c0124c70<= Trace; c0124d51 Trace; c0124f0c Trace; c0125038 Trace; c0107518 Code; c0124c70 <_EIP>: Code; c0124c70<= 0: 8b 73 04 movl 0x4(%ebx),%esi <= Code; c0124c73 3: 55pushl %ebp Code; c0124c74 4: 56pushl %esi Code; c0124c75 5: 53pushl %ebx Code; c0124c76 6: 57pushl %edi Code; c0124c77 7: e8 24 fe ff ffcall fe30 <_EIP+0xfe30> c0124aa0 Code; c0124c7c c: 83 c4 10 addl $0x10,%esp Code; c0124c7f f: 85 c0 testl %eax,%eax Code; c0124c81 11: 75 1d jne30 <_EIP+0x30> c0124ca0 Code; c0124c83 13: 8b 00 movl (%eax),%eax 1 warning and 1 error issued. Results may not be reliable. Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British
Re: Q: sock output serialization
>I sense that usually, LAPB handles this issue at a different >level, in the hardware? Does LAPB specify how to maintain >reliably delivery and could we hook into this "how" when we >need to drop LAPB frames? Perhaps it is too late by the time >netif_rx is dealing with it. LAPB maintains a window of (normally 8) frames. When a frame is accepted it as acked (RR) or if there is no room it is rejected (RNR). Once it has been accepted with an RR it can from that point onwards not get lost. > LAPB sounds like quite a broken protocol at the moment... But I'm > sure there are details which will emerge and clear this all up. LAPB isnt broken, its actually rather clever and ideal for tiny low power devices - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
In article <[EMAIL PROTECTED]>, Jeff Garzik <[EMAIL PROTECTED]> wrote: >When I sent Linus ten or twenty patches, that means I'm filling in ten >to twenty e-mail templates, yum :) Presumably that part of the process can be automated: $ cd /usr/src/linux $ ./scripts/submit-patch /tmp/patch-1 /tmp/patch-2 /tmp/patch3... The first time you'd run this hypothetical script, it would ask for template field values and offer to remember the ones that don't change often, such as the architecture you're working on. Presumably it would work in batch mode, too, if you had several related patches. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Rik's t8sched patch breaks pcmcia
--jho1yZJdad60DJr+ Content-Type: multipart/mixed; boundary*="ansi-x3-4-1968''OgqxwSJOaUobr8KG" Content-Disposition: inline --OgqxwSJOaUobr8KG Content-Type: text/plain; charset*=ansi-x3-4-1968''us-ascii Content-Disposition: inline 1st of all, THANKS RIK!!! Both patches are a godsend. I won't run a kernel w/out them. Your mojo's the best. I've got a Toshiba Satellite 2715 PIII 500 laptop with 128 MB RAM, running linux-2.4.0-test8 with + 2.4.0-t8-vmpatch2 and 2.4.0-t8-sched + reiserfs-3.6.14 Removing the sched patch from the mix makes cardmgr work. With the sched patch in, I get the following: (Attatched is a recorded session with output from lspci, /proc/cpuinfo, and everything that cardmgr spewed to syslog) starting, version is 3.1.20 watching 1 sockets could not adjust resource: IO ports 0xc00-0xcff: Input/output error could not adjust resource: IO ports 0x800-0x8ff: Input/output error could not adjust resource: IO ports 0x100-0x4ff: Input/output error could not adjust resource: memory 0xc-0xf: Input/output error could not adjust resource: memory 0x6000-0x60ff: Input/output error could not adjust resource: memory 0xa000-0xa0ff: Input/output error could not adjust resource: IO ports 0xa00-0xaff: Input/output error could not adjust resource: irq 4: Input/output error could not adjust resource: irq 7: Input/output error could not adjust resource: irq 12: Input/output error initializing socket 0 socket 0: Anonymous Memory executing: 'modprobe memory_cs' + modprobe: Can't locate module memory_cs modprobe exited with status 255 module /lib/modules/2.4.0-test8-t8vmpatch2-reiserfs-t8sched/pcmcia/memory_cs.o not available get dev info on socket 0 failed: Resource temporarily unavailable -Shawn Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. --OgqxwSJOaUobr8KG Content-Type: text/plain; charset*=ansi-x3-4-1968''us-ascii Content-Disposition: inline; filename*=ansi-x3-4-1968''session%2Etxt Content-Transfer-Encoding: quoted-printable Script started on Fri Sep 15 11:57:16 2000 bash-2.04#=20 bash-2.04#=20 bash-2.04#=20 bash-2.04# ps axf PID TTY STAT TIME COMMAND 1 ?S 0:00 init [S] =20 2 ?SW 0:00 [kapmd] 3 ?SW 0:00 [kswapd] 4 ?SW 0:00 [kreclaimd] 5 ?SW 0:00 [kflushd] 6 ?SW 0:00 [kupdate] 7 ?SW 0:00 [CardBus Watcher] 8 ?SW 0:00 [CardBus Watcher] 9 ?SW 0:00 [khubd] 174 tty1 S 0:00 init [S] =20 175 tty1 S 0:00 \_ /bin/sh 191 tty1 S 0:00 \_ script 192 tty1 S 0:00 \_ script 193 pts/0S 0:00 \_ bash -i 194 pts/0R 0:00 \_ ps axf bash-2.04# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 1 cpu MHz : 497.561962 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36= mmx fxsr xmm bogomips: 992.87 bash-2.04# lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (r= ev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev= 03) 00:05.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:05.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:05.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:05.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03) 00:07.0 Communication controller: Lucent Microelectronics 56k WinModem (rev= 01) 00:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus= Bridge with ZV Support (rev 20) 00:0b.1 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus= Bridge with ZV Support (rev 20) 00:0c.0 Multimedia audio controller: ESS Technology ES1978 Maestro 2E (rev = 10) 01:00.0 VGA compatible controller: Trident Microsystems Cyber 9525 (rev 49) bash-2.04#=20 bash-2.04#=20 bash-2.04#=20 bash-2.04# /etc/rc.d/init.d/pcmcia start Starting PCMCIA services: cardmgr. starting, version is 3.1.20 watching 1 sockets could not adjust resource: IO ports 0xc00-0xcff: Input/output error could not adjust resource: IO ports 0x800-0x8ff: Input/output error could not adjust resource: IO ports 0x100-0x4ff: Input/output error could not adjust resource: memory 0xc-0xf: Input/output error could not adjust resource: memory 0x6000-0x60ff: Input/output error could not adjust resource: memory 0xa000-0xa0ff: Input/output error could
MakeFile Problems - make modules_install test8
Last time I hit this I just ignored it, but it is still in test8
When running `make modules_install` it errors out with an
cd /lib/modules/2.4.0-test8; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.0-test8; fi
modprobe: kernel: QM_SYMBOLS: Function not implemented
make: *** [_modinst_post] Error 1
even tho pcmcia was never defined in the .config
Have to remove the _modinst_post in the `make modules_install` in order to
complete
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
Wizard Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
(604) 589-0037 Beautiful British Columbia, Canada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
On Fri, 15 Sep 2000, Russell King wrote: > Mitchell Blank Jr writes: > > If they're able to create a patch, hopefully they'd be able to fill in > > a simple email template (and I've seen some pretty dim folks manage to > > register domains with InterNIC, so email templates aren't that hard :-) > > > > We could even have a simple web page where you check a few boxes and > > fill in "URL to patch" and hit submit. > > You reckon? Its hard enough with mailing lists - I've seen people send > email subscription requests to majordomo@list to subscribe to a mailman > list, along with sending subscription requests to the mailing list address > etc. What makes you think that if humanity can't handle mailing lists > that humanity will handle an email template or a simple web page? >_ > |_| - ---+---+- > | | Russell King[EMAIL PROTECTED] --- --- > | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | > | +-+-+ --- -+- > / | THE developer of ARM Linux |+| /|\ > / | | | --- | > +-+-+ - /\\\ | Remember? This is not humanity. We're a community made of one Great Penguin (you guess who), few smaller penguins (kernel developers), and many many little rabbits (tring to learn something, with or without a debugger)... what has Mankind to do with us? B-) B-) B-) Anyway, you mean that one could: 1) read l-k, 2) choose an item from some TODO list, 3) download the kernel tarball and correctly untar it, 4) fire the editor of choice, 5) read the Source, 6) understand the Source, 7) contemplate It, 8) even dare to modify It, 9) produce a patch file with correct diff options, 10) find out the correct address to send the patch to, 11) launch the browser, and successfully open the form page, and after that stop for not being able to fill the template? You *really* believe this is a likely scenario? .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, Sep 15, 2000 at 05:39:35PM -, D. J. Bernstein wrote: > The absence of a non-blocking fd property causes reliability problems, > as discussed in http://cr.yp.to/docs/unixapi.html. I'd really like to > have ndelay_read() and ndelay_write() syscalls. You already have. Just pass MSG_DONTWAIT to send*/recv* -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
> "cort" == Cort Dougan <[EMAIL PROTECTED]> writes: Hi cort> } Now multiply my experience by the several hundred kernel developers out ^ cort> } there, and you can easily see how the kernel development community could cort> } easily have to invest a man-year or more learning how to use BK. But cort> If it takes a man-year to learn BK, that person shouldn't be doing kernel cort> work. It's beyond them. Putting shoes on would be a monumental effort of cort> mental power for them. I think ted means that it takes a man-year for the kernel comunity, not for a single person :) Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Richard B. Johnson wrote: > > The PCI Specification states, in part, that either the BIOS or the > driver has to enable the device. So, many drivers find that the device > has not been enabled. This is normal and necessary because many/most > PCI hardware had better not be enabled until an ISR is in-place. But that's why we have the "pci_enable_device()" function. And that's why we have the generic PCI setup functionality that finds and enables devices at the right addresses. DO NOT USE ANY LOCAL HACKS. Use the proper function. Don't go mucking around with random configuration state information: enabling a device involves a lot more than just writing stuff to configuration ports. Things like making sure the interrupt routing on the motherboard has been enabled, etc. Things that the driver does not know about, and should not even _try_ to understand. The PCI layer should be used to handle generic PCI issues. A low-level driver should _never_ try to handle resource allocation and enabling in hardware. Just as an example: imagine that the IO windows haven't been set up correctly. If the low-level driver just blindly enables IO cycles by writing to the PCI_COMMAND register, that device may come up in an invalid state, and mess up the whole system. The driver simply does not KNOW enough. It doesn't know where other devices are, and it _shouldn't_ know. In contrast, the general PCI layer _does_ know. It keeps track of resources, makes sure that different cards do not have overlapping address ranges, knows about PCI bridges (a card behind a PCI bridge can only be enabled after the _bridge_ has been enabled and can only be mapped in the region that the bridge maps). To make a long story short: a driver that touches the PCI_COMMAND or other generic PCI registers by hand is a _buggy_ driver. It's a sure recipe for disaster. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Fri, 15 Sep 2000, Linus Torvalds wrote: > > > On Wed, 13 Sep 2000, Andre Hedrick wrote: > > > > Okay who can teach me how to force hooks and ram this down the PPC > > > > pci_write_config_word(dev, PCI_COMMAND, 0x05); > > If the PPC PCI code doesn't do this, then that's a PPC architecture bug. > > DO NOT DO THIS IN THE DRIVER! Fix the real problem instead. > > Linus > The PCI Specification states, in part, that either the BIOS or the driver has to enable the device. So, many drivers find that the device has not been enabled. This is normal and necessary because many/most PCI hardware had better not be enabled until an ISR is in-place. So, the only safe place you can enable the device is in the driver. It is normal and the printk()'s warning about this should be removed. Also, the PCI_COMMAND should probably be 0x07 for all devices. The ones that "stay" are the ones actually supported. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Booting new kernel from running kernel
Hi, I'm trying to figure out a way to immediately boot a new kernel from within a running system. I do not care about gracefully shutting down the first kernel.. once I decide to run the new kernel, I'll abandon the first. I'm running from a system that consists of a kernel + initrd, and I'm running completely from the ramdisk. No disk, no lilo. This is a PowerPC system. Let's say I fetch a znetboot.initrd from somewhere. How do I get this new system to boot from my running system? Another way to look at this is that I want to use the first Linux kernel as a boot loader for the second. Some of the issues I see so far... I need to get the znetboot.initrd image into contiguous physical memory, without having previously reserved a sufficiently large space, so I can force a jump to the proper entry point, and initiate the normal Linux boot. It's trivial to get the image into a contiguous virtual space, but how does one allocate several megabytes of contiguous RAM in physical space, on the fly in a running system? Please CC: replies to me as I'm not subscribed to this list. Thanks, Frank. --- Frank Smith, MCompSci Principal Software Designer [EMAIL PROTECTED] AMIRIX Systems Inc. http://www.amirix.com/ Embedded Debian Project http://www.emdebian.org/ 77 Chain Lake Drive 902-450-1700 x289 (Phone) Halifax, N.S. B3S 1E1902-450-1704 (FAX) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
Russell King writes: > Richard Gooch writes: > > in a patch, then an email is sent to stating that a patch with > > ID has been applied. This would allow for automatic notification > > of the patch author when their patch has been applied. All that is > > needed is for Linus to update his patch binary. > > Why would the patch binary have to be touched? Do it the Unix > way(tm) and have a wrapper around patch which detects the relevent > line in the patch. (Note that patch will ignore any non-patch lines > automagically). Well, the patch programme doesn't have to specifically support the Notify: lines. But it would be good to be able to pass unrecognised lines to a separate file (or programme). It would allow other hacks like this in a robust way. But sure, we could just go for a simple script. Linus: would you use it? All you need do is: % cd `where patch` % mv patch patch.exe % mv ~/patch.wrapper patch and you'll never need to worry about it again. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
I'm going to work around this Linux bug in the next release of djbdns, just as I've worked around many other Linux bugs in the past. But the bug is going to continue to bite people. Matthias Andree writes: > Now, interpreting properties as "socket properties", and O_NONBLOCK > being a file descriptor property, O_NONBLOCK is not an fd property. It is an ofile property. Two different fds created by dup() will point to the same O_NONBLOCK bit. The absence of a non-blocking fd property causes reliability problems, as discussed in http://cr.yp.to/docs/unixapi.html. I'd really like to have ndelay_read() and ndelay_write() syscalls. ---Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre8
On Fri, Sep 15, 2000 at 05:34:23PM +0100, Alan Cox wrote: > > o Update NR_TASKS comment (Jarkko Kovala) The only limit cames from the GDT that can handle 8192 entries (8 bytes each), and each task needs two of them (one for LDT and one for the TSS) and the first 12 entries are reserved (not conditionally to APM). (8192-12)/2 = 4090 --- 2.2.18pre8/include/linux/tasks.hFri Sep 15 19:18:38 2000 +++ /tmp/tasks.hFri Sep 15 19:33:12 2000 @@ -11,7 +11,7 @@ #define NR_CPUS 1 #endif -#define NR_TASKS 512 /* On x86 Max about 4000 */ +#define NR_TASKS 512 /* On x86 Max 4090 */ #define MAX_TASKS_PER_USER (NR_TASKS/2) #define MIN_TASKS_LEFT_FOR_ROOT 4 Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH *] VM patch for 2.4.0-test8
On Thu, 14 Sep 2000, Rik van Riel wrote:
> On Wed, 13 Sep 2000, David S. Miller wrote:
>
> > In page_launder() about halfway down there is this sequence of tests
> > on LRU pages:
> >
> > if (!clearedbuf) {
> > ...
> > } else if (!page->mapping) {
> > ...
> > } else if (page_count(page) > 1) {
> > } else /* page->mapping && page_count(page) == 1 */ {
> > ...
> > }
> >
> > Above this sequence we've done a page_cache_get.
>
> Indeed, you're right. This bug certainly explains some
> of the performance things I've seen in the stress test
> last night...
>
> Btw, in case you're wondering ... the box /survived/
> a stress test that would get programs killed on quite
> a few "stable" kernels we've been shipping lately. ;)
Here comes a success report.
I've been using 2.4.0test8+2.4.0-t8-vmpatch2 for about a day now and the
performance is great.
I've just bought a new harddrive and I was copying a _lot_ of data to the
new drive and didn't notice anything axcept the HDD led flashing :)
And now I helped a friend back up his data while he converts to reiserfs.
I had a stream of 7-9MB/s down to my harddrive for quite a while and still
didn't notice anything. Everything ended up on the inactive list.
I've been trying to get my machine to swap but that seems hard with this
new patch :) I have 0kB of swap used after 8h uptime, and I have been
compiling, moving files between partitions and running md5sum on files
(that was a big problem before, everything ended up on the active list and
the swapping started and brought my machine down to a crawl)
I can mention that while backing up my friends data I had 7000-9000
interrupts per second and 10 000 - 12 000 context switches per second.
I was really impressed that I didn't notice anything. I remember that my
machine was terribly slow when it did over 5000 context switches with
vanilla test6.
(My machine is a pIII 700 with 256MB ram)
If anyone want more info or anything please feel free to mail me.
(Hopefully my mailserver is up, we've been experiencing some power
problems)
/Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Q: sock output serialization
From: [EMAIL PROTECTED] Date: Fri, 15 Sep 2000 21:07:38 +0400 (MSK DST) [ Dave, all this sounds bad. ] Well, there are two things: 1) If exact sequencing is so important, then we can make special netif_rx tasklet for these guys which serializes around a spinlock. Actually, even with this, how could we guarentee this still. Yes, IRQ affinity would need to force only a single CPU to receive interrupts from this LAPB device. It smells rotten to the core, can someone tell me exactly why reordering is strictly disallowed? I do not even know how other OSes can handle this properly since most, if not all, use the IRQ dynamic cpu targeting facilities of various machines so LAPB is by definition broken there too. 2) Someone please show Alexey and myself how to process input packet when out of memory and not to drop any packets ;-) I sense that usually, LAPB handles this issue at a different level, in the hardware? Does LAPB specify how to maintain reliably delivery and could we hook into this "how" when we need to drop LAPB frames? Perhaps it is too late by the time netif_rx is dealing with it. LAPB sounds like quite a broken protocol at the moment... But I'm sure there are details which will emerge and clear this all up. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
> " " == James Yarbrough <[EMAIL PROTECTED]> writes: > What is done for bypassing the cache when the size of a file > lock held by the reading/writing process is not a multiple of > the caching granularity? Consider two different clients with > processes sharing a file and locking 2k byte regions of the > file and possibly updating these regions. Suppose that each > system caches 4k byte blocks. If system A locks the first 2k > of a block and system B locks the second 2k, the updates from > one of the systems may be lost if these systems cache the > writes. This is because each system will write back the 4k > block it cached, not the 2k block that was locked. Under Linux writebacks have byte-sized granularity. If a page has been partially dirtied, we save that information, and only write back the dirty areas. As long as each system has restricted its updates to within the 2k block that it has locked, there should be no conflict. If however one system has been writing over the full 4k block, then there will indeed be a race. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test8 breaks ide-scsi
[ Sorry if this is already known, I have been too busy to read all lkml mail, ignore if so ] When ide-scsi is inserted it detects the drive(s) all over again in the following manner Detected scsi CD-ROM sr?? at scsi0, channel 0, id 0, lun 0 where ?? is a looping number, my guess is from 0 to infinity (well whatever the size is). This renders the system unusable. Other glitches I have noticed but haven't yet had time to work on, while booting: request_module[scsi_hostadapter]: Root fs not mounted request_module[scsi_hostadapter]: Root fs not mounted However I have only the SCSI options necessary for ide-scsi, this is a IDE-only system. Another thing is that either the kernel or the new modutils break RedHat's mixer-setting/sound detection scripts. (I have a es1371 based soundcard) However once the sound modules are manually inserted & mixer settings loaded, sound works just fine. I'm not sure but I think I saw this already with -test7. The kernel also breaks lmsensors but that's probably yet another story... Samuli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux RAS
I'd also want the default kernel build to create a symbol table namelist object that gets installed into $(INSTALL_PATH) that correlates to the kernel build. That way you build a symbol table mechanism for user-space applications that want more complete kernel debug information, but do it without bloating the kernel with all that gstabs data (which is duplicated many times over if you turn on -gstabs for an entire build). CONFIG_??* options are good to know about, but what really matters to me during debugging is how those CONFIG_??* settings actually change structure definitions. And the only way to really know that is to have the gstabs data outlining what is in the kernel. How does that sound? --Matt Daniel Phillips wrote: > > Keith Owens wrote: > > * Standardize on tracking the System.map and .config with the kernel. > > There was a suggestion from Alan Cox that .config.gz be appended to > bzImage, after the part that gets loaded into memory, to which I added > the suggestion that System.map.gz also be appended. That about takes > care of all the descriptive kernel information that normally gets out > of sync. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Q: sock output serialization
Hello! > But I realized another problem X.25 related SMP problem -- this time > related to input. The protocol design assumes that the transmission > path preserves the packet ordering. It seems that with 2.4.0 SMP, the ordering > of the packets when received from the wire is not necessarily the same > as when delivered to the protocol´s receive method. Is this true? This is true. > recover from such errors transparently. Unfortunatly, the current design > assumes that the LAPB layer is performed below the network interface. I.e. on hard irq? It was not a good idea. > Although this allows to support controllers which implement LAPB in firmware, This is really difficult case. > this seems to break the assumptions made by upper layers. The upper layer > assumes that LAPB devices provide a reliable datalink service. But the Linux > network interfaces do not preserve such reliable semantics. (Network > interfaces may drop frames, e.g. when NET_RX input queue overruns, No way to fix. I do not know how to make this. > and on SMP packet sequencing might change), Though this one can be fixed by restricting affinity, all this smells like you cannot use netif_rx() for such devices. netif_rx() is used for normal "unreliable" devices, it loses any sense as soon as we require some reliability... [ Dave, all this sounds bad. ] Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [bug report] pcmcia in kernel 2.4.0-test8
David Ford wrote: > > Summary: > > Kernel pcmcia code doesn't work. > DHinds pcmcia code works only if kernel pcmcia code is completely disabled. > USB Pegasus driver fails when kernel pcmcia code is enabled. > Kernel pcmcia code works fine with 2.4.0-test8 and my Xircom RBEM56G100TX, in fact I am writing from my laptop connected through it. See lsmod output and relevant part of .config. [asuardi@princess asuardi]$ lsmod Module Size Used by serial_cb 1456 1 xircom_tulip_cb30168 1 cb_enabler 2536 2 [serial_cb] ds 6540 2 [cb_enabler] yenta_socket9932 4 pcmcia_core39264 0 [cb_enabler ds yenta_socket] sb 1712 1 (autoclean) sb_lib 33660 0 (autoclean) [sb] uart401 6436 0 (autoclean) [sb_lib] [asuardi@princess asuardi]$ CONFIG_PCMCIA=m CONFIG_CARDBUS=y CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_XIRTULIP=m CONFIG_PCMCIA_SERIAL=m CONFIG_PCMCIA_SERIAL_CB=m The only hack I've done is to work around the known cardmgr issue with the 2.4 API not providing proper device names. I haven't tried 2.2.18pre7 but pre3 broke tulip_cb for the Xircom and pre5 hadn't fixed it yet. Ciao, --alessandro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Linux: kernel 2.2.18p5/2.4.0-t8 glibc-2.1.3 gcc-2.95.2 binutils-2.10.0.24 Oracle: Oracle8i 8.1.6.1.0 Enterprise Edition for Linux motto: Tell the truth, there's less to remember. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, 13 Sep 2000, Andre Hedrick wrote: > > Okay who can teach me how to force hooks and ram this down the PPC > > pci_write_config_word(dev, PCI_COMMAND, 0x05); If the PPC PCI code doesn't do this, then that's a PPC architecture bug. DO NOT DO THIS IN THE DRIVER! Fix the real problem instead. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux RAS
The comparison is was making was with OS/2, not MVS, because: 1) all too often MVS is cited as being the paradigm for RAS when infact there are special architectural features, as you've pointed out, that might detract from a generalised comparison. 2) OS/2 is an x86 based OS so has the problems, like Linux, of not being locked into tighlty controlled H/W architecture. 3) we completely reversed the serviceability situation for OS/2 and even exceeded the RAS capabilities of MVS in the area of dynamic tracing. Richard Moore - RAS Project Lead - Linux Technology Centre. http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 PISC, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK Keith Owens <[EMAIL PROTECTED]> on 15-09-2000 01:07:40 PM Please respond to Keith Owens <[EMAIL PROTECTED]> To: Richard J Moore/UK/IBM@IBMGB cc: [EMAIL PROTECTED] Subject: Linux RAS On Fri, 15 Sep 2000 10:42:54 +0100, [EMAIL PROTECTED] wrote: >I think the case for the kernel debugger is better stated as the case for >RAS (Reliability, Serviceability and Availability) in the kernel [snip] >Customers knew we never sent >developers on site to debug OS/390 (or MVS as it was called in those days). >They also knew that we never rejected a problem because it was not >re-creatable and we never even asked for a re-creation scenario. The reason >for this was that we had appropriate RAS capability in MVS which allowed >data to be captured automatically at fault time combined with a certain >amount of self-healing capability and automated recovery. It would be nice if Linux had the same level of RAS as MVS. But consider the different environments that MVS and Linux run under. MVS.Standard and external I/O controllers. Fix the data pages, build the CCW, issue SIO, forget about it until it interrupts. I/O requires little or no OS support, it can even be done from bare hardware. Linux. 50+ different I/O controllers. Most require continual hand holding by the operating system. Doing I/O from bare hardware is difficult if not impossible. MVS.Multiple systems keys (0-7) so different system components can be segregated. If VTAM (key 7) dies the rest of the OS (keys 0-6) can run. Multiple system keys stop most runaway components from stamping on other component's data. Key switching is relatively cheap. Linux. On ix86, all of the kernel runs in key 0. No protection of one part of the kernel from another. Key switching is relatively expensive. MVS.High quality hardware. Processors that can detect their own problems, all memory is ECC or better, disks that report failures before they occur. Linux. Most users are on the cheapest possible hardware. No parity on memory, processors and disks that just die without warning. Lots of random problems, "one bit different, probably bad RAM". MVS.Trace of interesting events in the master trace table. Linux. No kernel trace table (oops backtrace does *not* count). MVS.Only one hardware model - S/390 with minimum hardware requirements for each version of OS/390. IBM can get away with telling customers "to run OS/390 2.9 you need a G5 processor or better". Linux. 12+ different hardware models, with no restriction on how old the hardware is. We cannot tell customers "to run Linux 2.4 you must have a Pentium III or better". MVS.If all else fails, MVS can do a stand alone IPL to capture the crash data. It requires that a site plan ahead by building stand alone IPL text and dedicating an area of disk to receive the crash dump but apart from that it always works. Linux. Assuming that your I/O subsystem will run without a working OS (and lkcd shows how difficult that is), you still need a mechanism to get the stand alone dump going. On our most common platform (ix86) we have to pray that the BIOS will not wipe memory before saving the crash dump. If the BIOS is not reliable (and most are not) then the stand alone code must be built into the kernel and protected somehow. Then you have the problem of activating the stand alone dump. MVS.Decent hardware support for OS tracing, with Program Event Registers (PER) that are standardized and easy to use. Linux. Each platform has different hardware mechanisms for hardware debugging. Some have no hardware debugging at all. MVS.The OS developers know everything about the hardware. They even know the undocumented processor and I/O subsystem commands. Linux. Nobody knows everything about every bit of hardware that is supported. MVS.Decent hardware support for cheap cross memory services. OS data can be separated into multiple data
Linux 2.2.18pre5
Still knocking bugs out... 2.2.18pre8 o Fix mtrr compile bug(Peter Blomgren) o Alpha PCI boot up fix (Michal Jaegermann) o Fix vt/keyboard dependancy in USB config(Arjan van de Ven) o Fix sound hangs on cs4281 (Tom Woller) o Fix Alpha vmlinuz.lds (Andrea Arcangeli) o Fix CDROMPLAYTRKIND bug, allow root to open (Jens Axboe) the cd door whenver. o Update ov511 to match 2.4 (Greg Kroah-Hartman) o Further devio.c fix (Greg Kroah-Hartman) o Update NR_TASKS comment (Jarkko Kovala) o Further sparc64 ioctl translator fixes (Andi Kleen) 2.2.18pre7 o Fix the AGP compile in bug (Arjan van de Ven) o Revert old incorrect syncppp state change (Ivan Passos) o Fix i810 rng to actually get built in (Arjan van de Ven) o Megaraid compile fix, joystick, mkiss fixes (Arjan van de Ven) o Kawasaki USB ethernet depends on net(Arjan van de Ven) o Compaq cpqarray update (Charles White) o Fix usb problem with no USB unit found (Oleg Drokin) o Driver for the radio on some maestro cards (Adam Tlalka) o Additional shared map support needed for sparc64(Dave Miller) o Fix wdt_pci when compiled in(me, Arjan van de Ven) o Fix usb missing symbol when non modular (Arjan van de Ven) o Identify chip and also handle MTRR for the (me) Cyrix III o Allow binding to all ports multicast(Andi Kleen) o Bring USB docs up to date (Greg Kroah-Hartman) o Bring USB devio up to date (Greg Kroah-Hartman) o pci_resource_len null function for non PCI case (Arjan van de Ven) o Fix synchronous write off end of disk bug (Jari Ruusu) 2.2.18pre6 o Fix the IDE PCI not compiling bug (Dag Wieers) o Kill an escaped reference to vger.rutgers (Dave Miller) o Small rtl8139 fixups(Jeff Garzik) o Add USB bluetooth driver(Greg Kroah-Hartman) o Fix oops in visor driver(Greg Kroah-Hartman) o Remove some unneeded ext2 includes,fix a bug(Andreas Dilger) in the UFS code o Fix rtc race between timer and rtc irq (Andrea Arcangeli) o Fix slow gettimeofday SMP race (Andrea Arcangeli) o Check lost_ticks in settimeofday to be more (Andrea Arcangeli) precise 2.2.18pre5 o Added older VIA ide chipsets to the not to be (me) autotuned list o Fix crash on boot problem with __setup stuff(me) o Small acenic fix(Matt Domsch) o Fix hfc_pci isdn driver (Jens David) o Fix smbfs configuration problem (Urban Widmark) o Emu10K wrapper/build fixes (Rui Sousa) o Small cleanups (Arjan van de Ven) o Fix sparc32 build bug (Horst von Brand) o Fix quota oops (Martin Diehl) o Add i810 random number driver (Jeff Garzik) o Clear suid bits on ext2 truncate as per SuS (Andi Kleen) o Fix illegal use of section attributes (Arjan van de Ven) o Documentation for nmi watchdog (Marcelo Tosatti) o Fix uninitialised variable warnings (Arjan van de Ven) o Save DR6 condition into the TSS (Ryan Wallach) o Add additional __init's to the kernel (Andrzej M. Krzysztofowicz) o Backport 2.4 wdt_pci driver (JP Nollman, me) o AGP i810 fixes (Chip Salzenberg) o UDMA support for ALI1543 & 1543C IDE devices(ALI) o 2.4 MSR/CPUID driver backport (Dave Jones, H Peter Anvin) o Fix incorrect use of kernel v user ptr in NCPfs (Petr Vandrovec) o Updated scsi tape driver(Kai Makisara) 2.2.18pre4 o Remove the aacraid driver again, having looked (me) at what is needed to make it acceptable and debug it - Im dumping it back on Adaptec o DAC960 update (Leonard Zubkoff) o Add setup vmlinuz.lds changes for Sparc (Arjan van den Ven) o Sparc updates for drm, ioctl and other (Dave Miller) o Megaraid driver update (Peter Jarrett) o Add cd volume 0 to the amp power off on the crystal cs46xx
Re: No Bug: accept discards socket options/O_NONBLOCK
On Fri, Sep 15, 2000 at 07:01:32AM -0700, David S. Miller wrote: > Every Linux inetd in the world would instantly stop working. Pointer to docs on why this is not considered a bug in inetd? Also, you already know how to upgrade a syscall without breaking backwards compatability. > The behavior is not changing, lets end this thread right now. I'm not trying to say the behavior must change -- I'm trying to find out why it won't. ["I don't see the need", is something that I'd accept. However, "it would break inetd" doesn't make sense.] -- Raul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Bug in 3w-xxxx.c (Notifiers STILL broken)
This is due to a bug in kernel/sys.c in the function notifier_chain_unregister(). where the 'notifier_lock' can't be acquired while reboot is running. I suspect any other drivers that call this function on shutdown from unregister_reboot_notifier() (in the case where the root filesystem is mounted through the driver will also have this problem), i.e. DAC960.c (Mylex) and gdth.c (ICP). The fix for now is to modify kernel/sys.c, the function "notifier_chain_unregister", and remove the write_lock(_lock), and write_unlock(_lock) calls from this function and recompile your kernel. -- Adam Radford Software Engineer 3ware, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, September 15, 2000 12:49 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Bug in 3w-.c Hi, i have discovered a problem with a 3ware 5400 controller inside my SMP system (Dual PIII800, kernel 2.4.0-test7, 3w-.c version 1.02.00.002). Problem: System will not reboot or halt. Last message on console comes form within 3w-.c. Solution: remove call to function unregister_reboot_notifier() in function tw_halt() solves the problem. Regards, Frank Koeck --- Frank Koeck Max-Planck-Institut fuer Kernphysik, Saupfercheckweg 1, D-69117 Heidelberg Phone: +49-6221-516-518 Fax: +49-6221-516-602 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Hello! > This has been this way forever, it is thus an API and it is not > changing. Changing it would break existing programs. End of story. 8) However, imagine, freebsd folks changed this in their release 2.x. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
> This will always invalidate the page cache whenever we try to obtain > the lock, hence you are guaranteed that the cache will be reread after > the lock was grabbed. > After unlocking however one needs no guarantees other than ensuring > that any modifications were committed while we held the lock, so we > flush the writebacks, drop the lock, and leave it at that. What is done for bypassing the cache when the size of a file lock held by the reading/writing process is not a multiple of the caching granularity? Consider two different clients with processes sharing a file and locking 2k byte regions of the file and possibly updating these regions. Suppose that each system caches 4k byte blocks. If system A locks the first 2k of a block and system B locks the second 2k, the updates from one of the systems may be lost if these systems cache the writes. This is because each system will write back the 4k block it cached, not the 2k block that was locked. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, Sep 13, 2000 at 05:31:17PM -0400, Richard B. Johnson wrote: > On 13 Sep 2000, Ralf Gerbig wrote: > > > * Chip Salzenberg writes: > > > > Hi Chip, > > > > > According to Ralf Gerbig: > > >> but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. > > > > > You've just made L-K's understatement of the day. > > > > [...] > > > > so I rest my case vs shrink wrap. > > > > Yep. I installed Suse-6.4 on my laptop. Since I needed APM to work, I > recompiled the kernel source that they supplied. First, I just did > `make oldconfig` so I could duplicate the existing kernel. Well. > No such luck. There was no way in hell I could duplicate the kernel > that they supplied, with the sources that they supplied. And there > was no secret 'patch' directory either... I'm not sure (don't have a SuSE box right here) but I think they have separate packages for patched and unpatched kernel sources. I also remember their kernel patches are even separately stored somewhere. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux RAS
Keith Owens wrote: > * Standardize on tracking the System.map and .config with the kernel. There was a suggestion from Alan Cox that .config.gz be appended to bzImage, after the part that gets loaded into memory, to which I added the suggestion that System.map.gz also be appended. That about takes care of all the descriptive kernel information that normally gets out of sync. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCEMENT] pre-patch-2.0.39final
On Fri, 15 Sep 2000, Alan Cox wrote: > > too loudly about pre8, so it can't be that bad. Oh, and don't bicker > > and argue about the devfs files. It's not devfs itself, only headers. > > Whine bicker bitch moan complain ;) > > I'll go over it in detail early next week You know, one thing that seems to be a general truth is that people don't report problems until you hold the gun to their head, and count down from 10. Usually, they speak up at 2 or 1. It's probably due to seeing too many Hollywood movies. To prove this, I got a bugreport today. A bug that seems to have been introduced in pre4, which was released 25th of April. One would expect that bug to have been reported sooner, right? Hell no. Why report the bug when you can fall back to pre3 and be happy?! :^) Oh well. The backdraw with announcing a final is that it only works once or twice, then the people who don't experience bugs and want the proper final version get fed up. /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
Matthias Andree <[EMAIL PROTECTED]> writes: > On Fri, 15 Sep 2000, David S. Miller wrote: > > > Every Linux inetd in the world would instantly stop working. > > Why should it? inetd.c does not touch fd flags. No F_SETFL, no > O_NONBLOCK, no fcntl. Why should inetd fail with a changed accept(2) > semantics? Most of the programs called by inetd don't expect non-blocking I/O on their stdin and stdout, which they would suddenly get if accept()'ed sockets inherited the non-blocking nature of inetd's listening socket. Personally, I think that the common case is that the caller will want the same blocking attribute for an accept()'ed socket as on the listening socket it came from, and inetd is the only app I have seen offered as a counterexample. If it's just one app, it can easily be changed and marked as required for upgrades to kernels that have the same semantics as the BSDs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
Russell King writes: > Mitchell Blank Jr writes: > > If they're able to create a patch, hopefully they'd be able to fill in > > a simple email template (and I've seen some pretty dim folks manage to > > register domains with InterNIC, so email templates aren't that hard :-) > > > > We could even have a simple web page where you check a few boxes and > > fill in "URL to patch" and hit submit. > > You reckon? Its hard enough with mailing lists - I've seen people > send email subscription requests to majordomo@list to subscribe to a > mailman list, along with sending subscription requests to the > mailing list address etc. What makes you think that if humanity > can't handle mailing lists that humanity will handle an email > template or a simple web page? Humanity can't handle patching kernels either. And with the Darwinist development model, those who can't fill in the template have their patches go to /dev/null ;-) Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
