Re: [PATCH] compiler warning fixes in 8139too.c
Anuradha writes: > The following patch fixes some warnings when 8139 driver is compiled > without 8129 support. I've already submitted an improved patch to Jeff Garzik (8139too maintainer) that fixes this issue and he will include along with other fixes to the driver when he updates it next. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Tue, 29 May 2001, Vincent Stemen wrote: > On Tuesday 29 May 2001 15:16, Alan Cox wrote: > > > a reasonably stable release until 2.2.12. I do not understand why > > > code with such serious reproducible problems is being introduced into > > > the even numbered kernels. What happened to the plan to use only the > > > > Who said it was introduced ?? It was more 'lurking' than introduced. And > > unfortunately nobody really pinned it down in 2.4test. > > > > I fail to see the distinction. First of all, why was it ever released > as 2.4-test? That question should probably be directed at Linus. If > it is not fully tested, then it should be released it as an odd > number. If it already existed in the odd numbered development kernel > and was known, then it should have never been released as a production > kernel until it was resolved. Otherwise, it completely defeats the > purpose of having the even/odd numbering system. > > I do not expect bugs to never slip through to production kernels, but > known bugs that are not trivial should not, and serious bugs like > these VM problems especially should not. And you can help prevent them from slipping through by signing up as a shake and bake tester. Indeed, you can make your expectations reality absolutely free of charge, and or compensation what a bargain! X ___ ;-) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Emulate RDTSC
On Tue, 29 May 2001, Jaswinder Singh wrote: > What is the nice way (in accuracy and performance) to emulate RDTSC in > Linux for those architectures who dont support RDTSC like in Hitachi > SH Processors. if the hardware provides no way to get some accurate estimation of current time, then there is no way to solve this problem in a generic way. Typically there are some cycle-accuracy counters in the CPU (ideal situation), or sometimes there is a counter in some external device (eg. the i8254 timer counter), but access to these tend to be slow and typically they are quite coarse as well. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 4 security holes in 2.4.4-ac8
On Tue, 29 May 2001, Dawson Engler wrote: > > Believe it or not, this one is OK :-) > > > > All callers pass in a pointer to a local stack kernel variable > > in raddr. > > Ah. I assumed that "sys_*" meant that all pointers were from user > space --- is this generally not the case? (Also, are there other > functions called directly from user space that don't have the sys_* > prefix?) to automate this for the Stanford checker i've attached the 'getuserfunctions' script that correctly extracts these function names from the 2.4.5 x86 entry.S file. unfortunately the validation of the script will always be manual work, although for the lifetime of the 2.4 kernel the actual format of the entry.S file is not going to change. To make this automatic, i've added a md5sum to the script itself, if entry.S changes then someone has to review the changes manually. It's important to watch the md5 checksum, because new system-calls can be added in 2.4 as well. a few interesting facts. Functions that are called from entry.S but do not have the sys_ prefix: do_nmi do_signal do_softirq old_mmap old_readdir old_select save_v86_state schedule schedule_tail syscall_trace do_divide_error do_coprocessor_error do_simd_coprocessor_error do_debug do_int3 do_overflow do_bounds do_invalid_op do_coprocessor_segment_overrun do_double_fault do_invalid_TSS do_segment_not_present do_stack_segment do_general_protection do_alignment_check do_page_fault do_machine_check do_spurious_interrupt_bug functions in the kernel source that have the sys_ prefix and use asmlinkage but are not called from the x86 entry.S file: sys_accept sys_bind sys_connect sys_gethostname sys_getpeername sys_getsockname sys_getsockopt sys_listen sys_msgctl sys_msgget sys_msgrcv sys_msgsnd sys_recv sys_recvfrom sys_recvmsg sys_semctl sys_semget sys_semop sys_send sys_sendmsg sys_sendto sys_setsockopt sys_shmat sys_shmctl sys_shmdt sys_shmget sys_shutdown sys_socket sys_socketpair sys_utimes the list is pretty big. There are 33 functions that are called from entry.S but do not have the sys_ prefix or do not have the asmlinkage declaration. NOTE: there are other entry points into the kernel's 'protection domain' as well, and not all of them are through function interfaces. Some of these interfaces pass untrusted pointers and/or untrusted parameters directly, but most of them pass a pointer to a CPU registers structure which is stored on the kernel stack (thus the pointer can be trusted), but the contents of the registers structure are untrusted and must not be used unchecked. 1) IRQ handling, trap handling, exception handling entry points. I've atttached the 'getentrypoints' script that extracts these addresses from the i386 tree: divide_error debug int3 overflow bounds invalid_op device_not_available double_fault coprocessor_segment_overrun invalid_TSS segment_not_present stack_segment general_protection spurious_interrupt_bug coprocessor_error alignment_check machine_check simd_coprocessor_error system_call lcall7 lcall27 all of these functions get parameters passed that are untrusted. 2) bootup parameter passing. there is a function entry point, start_kernel, but there is also lots of implicit parameter passing, values filled out by the boot code, and parameters stored in hardware devices (eg. PCI settings and more). These all are theoretical protection domain entry points, but impossible to check automatically - the validity of current system state will have to be checked manually. (and in most cases it can be trusted - but not all cases.) Some 'unexpected' boot-time entry points: initialize_secondary on SMP systems for example. 3) manually constructed unsafe entry points which are hard to automate. include/asm-i386/hw_irq.h's BUILD macros are used in a number of places. One type of IRQ building uses do_IRQ() as an entry point. The SMP code builds the following entry points: reschedule_interrupt invalidate_interrupt call_function_interrupt apic_timer_interrupt error_interrupt spurious_interrupt but most of these pass no parameters, but apic_timer_interrupt does get untrusted parameters. 4) BIOS exit/entry points, eg in the APM code. Impossible to check, we have to trust the BIOS's code. i think this mail should be a more or less complete description of all entry points into the kernel. (Let me know if i missed any of them, or any of the scripts misidentifies entry points.) Ingo grep -E 'set_trap_gate|set_system_gate|set_call_gate' arch/i386/*/*.c arch/i386/*/*.h | grep -v 'static void' | cut -d, -f2- | sed 's/&//g' | cut -d\) -f1 if [ "`md5sum arch/i386/kernel/entry.S`" != "0e19b0892f4bd25015f5f1bfe90b441a arch/i386/kernel/entry.S" ]; then echo "entry.S file's MD5sum changed! Please revalidate the changes and change the md5sum in this script."; exit -1; fi (grep 'call S' arch/i386/kernel/entry.S | grep '[()]'; grep '\.long
[PATCH] compiler warning fix in aci.c
Following patch fixes a compiler warning in aci.c.
Regards,
Anuradha
--
http://www.bee.lk/people/anuradha/
diff -rua linux-2.4.5/drivers/sound/aci.c linux/drivers/sound/aci.c
--- linux-2.4.5/drivers/sound/aci.c Tue May 29 23:42:11 2001
+++ linux/drivers/sound/aci.c Wed May 30 01:21:14 2001
@@ -95,18 +95,6 @@
MODULE_PARM_DESC(wss,"change between ACI/WSS-mixer; use 0 and 1 - untested"
" default: do nothing; for PCM1-pro only");
-static void print_bits(unsigned char c)
-{
- int j;
- printk(KERN_DEBUG "aci: ");
-
- for (j=7; j>=0; j--) {
- printk(KERN_DEBUG "%d", (c >> j) & 0x1);
- }
-
- printk(KERN_DEBUG "\n");
-}
-
/*
* This busy wait code normally requires less than 15 loops and
* practically always less than 100 loops on my i486/DX2 66 MHz.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] compiler warning fixes in 8139too.c
The following patch fixes some warnings when 8139 driver is compiled
without 8129 support.
Regards,
Anuradha
--
http://www.bee.lk/people/anuradha/
diff -rua linux-2.4.5/drivers/net/8139too.c linux/drivers/net/8139too.c
--- linux-2.4.5/drivers/net/8139too.c Tue May 29 23:41:48 2001
+++ linux/drivers/net/8139too.c Wed May 30 01:00:21 2001
@@ -1150,6 +1150,7 @@
0
};
+#ifdef CONFIG_8139TOO_8129
/* Syncronize the MII management interface by shifting 32 one bits out. */
static void mdio_sync (void *mdio_addr)
@@ -1168,14 +1169,18 @@
DPRINTK ("EXIT\n");
}
+#endif
static int mdio_read (struct net_device *dev, int phy_id, int location)
{
struct rtl8139_private *tp = dev->priv;
+ int retval = 0;
+
+#ifdef CONFIG_8139TOO_8129
void *mdio_addr = tp->mmio_addr + Config4;
int mii_cmd = (0xf6 << 10) | (phy_id << 5) | location;
- int retval = 0;
int i;
+#endif
DPRINTK ("ENTER\n");
@@ -1216,9 +1221,12 @@
int value)
{
struct rtl8139_private *tp = dev->priv;
+
+#ifdef CONFIG_8139TOO_8129
void *mdio_addr = tp->mmio_addr + Config4;
int mii_cmd = (0x5002 << 16) | (phy_id << 23) | (location << 18) | value;
int i;
+#endif
DPRINTK ("ENTER\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Generating valid random .configs
Recently, I posted a request here to send your .config files and I received a good number of them. (thanks!). Now I want to generate even more different configurations, and a random .config generator would be ideal. If I write a program which randomly outputs "y", "m" and "n" and pipe its output through make config, will the generated .configs always compile? Yes. the best thing is to go ahead and try it (which I am doing at the moment) but I like to know the theoretical answer;) Thanks in advance. Regards, Anuradha -- http://www.bee.lk/people/anuradha/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFF-TOPIC] 4 ports ETH cards
Hi Dan, yes it's more or less like this. I got many mail explaining me. I will forward the most interesting to you. Thanks Fabio Dan Hollis wrote: > > On Tue, 29 May 2001, Fabbione wrote: > > I found some cards based on the DEC 21*4* chips but when > > I asked for more details I got a strange answer from the reseller > > like that this card is able to work only half-duplex and the chip has > > only one mac-address for the 4 eth cards (really strange). > > This sounds like it's not a 4 port card, but a 4 port hub-card. (Eg a card > with integrated 4-port hub) > > -Dan -- Fabio Massimo Di Nitto Debian GNU/Linux Testing/Unstable Kernel 2.4.3 Office for the Complication of Otherwise Simple Affairs PROUD TO BE MICROSOFT FREE! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reproducible oops when loading ns558.o in 2.4.5-ac4
On Tue, May 29, 2001 at 11:08:13PM +0100, Stephen Thomas wrote: Just one question: How to reproduce it? Just by loading the module? > ksymoops 2.3.7 on i686 2.4.5-ac4. Options used > -v linux-2.4.5-ac4/vmlinux (specified) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.5-ac4/ (default) > -m linux-2.4.5-ac4/System.map (specified) > > May 29 22:40:52 wycliffe kernel: Unable to handle kernel paging request at virtual >address 3d83537a > May 29 22:40:52 wycliffe kernel: c01a8d27 > May 29 22:40:52 wycliffe kernel: *pde = > May 29 22:40:52 wycliffe kernel: Oops: > May 29 22:40:52 wycliffe kernel: CPU:0 > May 29 22:40:52 wycliffe kernel: EIP:0010:[isapnp_find_dev+59/256] > May 29 22:40:52 wycliffe kernel: EFLAGS: 00010213 > May 29 22:40:52 wycliffe kernel: eax: 3d835356 ebx: cc8a36e4 ecx: >edx: cc8a348c > May 29 22:40:52 wycliffe kernel: esi: 0002 edi: 0002 ebp: 0100 >esp: cb12dedc > May 29 22:40:52 wycliffe kernel: ds: 0018 es: 0018 ss: 0018 > May 29 22:40:52 wycliffe kernel: Process modprobe (pid: 662, stackpage=cb12d000) > May 29 22:40:52 wycliffe kernel: Stack: cc8a36e4 cc8a348c 0001 cc8a382c cc8a3000 >cc8a3824 00ff 0002382c > May 29 22:40:52 wycliffe kernel:cc8a34f5 0002 0100 cc8a348c >cc8a3000 cc8a348c c0114b28 > May 29 22:40:52 wycliffe kernel:cb12c000 0804b52b 08061d70 bfffc45c 0001 >cc8a1000 cc8a1000 cc8a3818 > May 29 22:40:52 wycliffe kernel: Call Trace: [] [] [] >[] [] > May 29 22:40:52 wycliffe kernel:[] [] [] >[] [sys_init_module+1424/1588] [] > May 29 22:40:52 wycliffe kernel:[] [] [] >[] [system_call+51/56] > May 29 22:40:52 wycliffe kernel: Code: 66 39 78 24 75 0a 66 39 68 26 0f 84 ab 00 00 >00 31 c9 8d 70 > Using defaults from ksymoops -t elf32-i386 -a i386 > > Trace; cc8a36e4 <[ns558]pnp_devids+4/48> > Trace; cc8a348c <[ns558]init_module+0/0> > Trace; cc8a382c <[ns558].bss.end+15/1d> > Trace; cc8a3000 <[gameport]__kstrtab_gameport_cooked_read+1a47/1aa7> > Trace; cc8a3824 <[ns558].bss.end+d/1d> > Trace; cc8a34f5 <[ns558]ns558_init+69/90> > Trace; cc8a348c <[ns558]init_module+0/0> > Trace; cc8a3000 <[gameport]__kstrtab_gameport_cooked_read+1a47/1aa7> > Trace; cc8a348c <[ns558]init_module+0/0> > Trace; cc8a1000 <[joydev]__module_device+185d/18bd> > Trace; cc8a3818 <[ns558].bss.end+1/1d> > Trace; cc8a1000 <[joydev]__module_device+185d/18bd> > Trace; cc8a3060 <[ns558]ns558_isa_probe+0/2b8> > Code; Before first symbol > <_EIP>: > Code; Before first symbol >0: 66 39 78 24 cmp%di,0x24(%eax) > Code; 0004 Before first symbol >4: 75 0a jne10 <_EIP+0x10> 0010 Before first symbol > Code; 0006 Before first symbol >6: 66 39 68 26 cmp%bp,0x26(%eax) > Code; 000a Before first symbol >a: 0f 84 ab 00 00 00 je bb <_EIP+0xbb> 00bb Before first symbol > Code; 0010 Before first symbol > 10: 31 c9 xor%ecx,%ecx > Code; 0012 Before first symbol > 12: 8d 70 00 lea0x0(%eax),%esi > > The module loaded OK in 2.4.5-ac3. input, joydev, ns558, gameport and analog > are all configured as modules. > > Stephen Thomas -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ov511.c
The ov511 driver fails to compile in 2.4.5 gcc -D__KERNEL__ -I/home/stephenc/kernel/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-c -o ov511.o ov511.c ov511.c: In function ov511_read_proc': ov511.c:340: version' undeclared (first use in this function) ov511.c:340: (Each undeclared identifier is reported only once ov511.c:340: for each function it appears in.) make[4]: *** [ov511.o] Error 1 make[4]: Leaving directory /home/stephenc/kernel/linux/drivers/usb' -- Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 still breaks dhcpcd with 8139too
On Wed, May 30, 2001 at 01:05:04AM -0400, Jeff Garzik wrote: > > I've got one of the two problems fixed here at the test lab, and am > working on the second. Hopefully this week I'll have this sorted out, > and a driver for you guys to test. Sounds great, let me know when you have it sorted out and I'll give it a whirl over here. -Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Part I of Lameness...
> General bitching pisses me off, especially when you are dead wrong. A little maturity goes a long way. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pdc20268 error?
Not an error. The new PDC20268 has all the register data hidden form the user. Another anti-user-friendly reaction by Promise Technology. However, the up side is that they were smart enough to make the taskfile registers for the setfeatures command auto set the host values. Basically there are no data points that can be read from the new TX2 that have any real trustable world meaning. Cheers, On Tue, 29 May 2001, Vasile Gaburici wrote: > Date: Tue, 29 May 2001 22:41:38 -0400 (EDT) > From: Vasile Gaburici <[EMAIL PROTECTED]> > To: Andre Hedrick <[EMAIL PROTECTED]> > Subject: pdc20268 error? > > > Hi, > > I've got a Promise Ultra100 TX2 board to work with 2.2.19 plus > your ide.2.2.19.05042001 patch. I've only attached one UDMA33 capable > CD-ROM drive to the primary a channel of the card to see how things go. I > can mount access it okay (via hde). > > The fact that troubles me is that 'cat /proc/ide/pdc202xx' seems > to indicate that the board is in error and cannot determine PIO and DMA > modes for the devices (see attachments). Is this normal for my config or > is it a bug? > > Also, I'd like to know if the shortcuts in the driver for 20268 > (various gotos that skip code) are mandated by some improved hardware or > just lack of info for the 20268... > > > Thanks, > Vasile > > P.S.: Is there a list for ide-only discussion? 200/day on lklm is > too much for me... > Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 still breaks dhcpcd with 8139too
David Rees wrote: > > Hi, > > dhcpcd is still broken in 2.4.5 when using the stock 8139too driver as > referenced in this thread: > http://marc.theaimsgroup.com/?t=9884722973=2=1 > > Going back to the 8139too driver in 2.4.3 fixes it. > > I see that Alan has reverted back to the 2.4.3 driver for his ac-series for > other reasons, hopefully either the old driver will going in to 2.4.6 or the > new one will get fixed? I've got one of the two problems fixed here at the test lab, and am working on the second. Hopefully this week I'll have this sorted out, and a driver for you guys to test. -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5 still breaks dhcpcd with 8139too
Hi, dhcpcd is still broken in 2.4.5 when using the stock 8139too driver as referenced in this thread: http://marc.theaimsgroup.com/?t=9884722973=2=1 Going back to the 8139too driver in 2.4.3 fixes it. I see that Alan has reverted back to the 2.4.3 driver for his ac-series for other reasons, hopefully either the old driver will going in to 2.4.6 or the new one will get fixed? -Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Swap problems persisting?
On Tue, 29 May 2001 22:55:43 Alan Cox wrote: >> I found myself in trouble with sudden shutdowns while playing DVDs (LiViD) and >sometimes >> running Mozilla 0.8.1 simultaneously, but running mozilla wasn't always necessary. >> > >Describe "sudden shutdown" more precisely first of all > I'm terribly sorry for my unprecise description. By "sudden shutdown" I meant that the machine freezes hard and when running X using the Magic SysRq key combinations don't seem to work so power cycling was the only option. It seems that it wasn't just the keyboard that had frozen because a webserver I'm running on the machine also stopped serving pages. Thanks, Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM
Mike Galbraith ([EMAIL PROTECTED]) wrote: > > Emphatic yes. We went from cache collapse to cache bloat. Rik, I think Mike deserves his beer. ;) Agreed. Swap reclaim doesn't seem to be the root issue here, IMHO. But instead: his box was capable of maintaining a modest cache and the desired user processes without massive allocations (and use) of swap space. There was plenty of cache to reap, but VM decided to swapout instead. Seems we're out of balance here (IMHO). I see this too, and it's only a symptom of post-2.4.4 kernels. Example: on a 128M system w/2.4.5, loading X and a simulation code of RSS=70M causes the system to drop 40-50M into swap...with 100M of cache sitting there, and some of those cache pages are fairly old. It's not just allocation; there is noticable disk activity associated with paging that causes a lag in interactivity. In 2.4.4, there is no swap activity at all. And if the application causes heavy I/O *and* memory load (think StarOffice, or Quake 3), this situation gets even worse (because there's typically more competition/demand for cache pages). And on low-memory systems (ex. 32M), even a basic Web browsing test w/ Opera drops the 2.4.5 system 25M into swap where 2.4.4 barely cracks 5 MB on the same test (and the interactivity shows). This is all independent of swap reclaim. So is there an ideal VM balance for everyone? I have found that low-RAM systems seem to benefit from being on the "cache-collapse" side of the curve (so I prefer the pre-2.4.5 balance more than Mike probably does) and those low-RAM systems are the first hit when, as now, we're favoring "cache bloat". Should balance behaviors could be altered by the user (via sysctl's maybe? Yeah, I hear the cringes)? Or better, is it possible to dynamically choose where the watermarks in balancing should lie, and alter them automatically? 2.5 stuff there, no doubt. Balancing seems so *fragile* (to me). Cheers, Craig Kulesa [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Part I of Lameness...
Since this was filtered the first time...
Andre Hedrick
Linux ATA Development
-- Forwarded message --
Date: Mon, 28 May 2001 23:21:57 -0700 (PDT)
From: Andre Hedrick <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Lacking Performance my ARSE!
beetle:~ # hdparm -it /dev/hda
/dev/hda:
Model=Maxtor 5T020H2, FwRev=TAH71DP0, SerialNo=T2J0HBRC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=39062500
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6
Kernel Drive Geometry LogicalCHS=2431/255/63 PhysicalCHS=38752/16/63
Timing buffered disk reads: 64 MB in 1.75 seconds = 36.57 MB/sec
fttk:~ # hdparm -it /dev/hda
/dev/hda:
Model=IBM-DTLA-307020, FwRev=TX3OA50C, SerialNo=YHDYHT9S024
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40188960
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Drive Supports : Reserved : ATA-2 ATA-3 ATA-4 ATA-5
Kernel Drive Geometry LogicalCHS=2501/255/63 PhysicalCHS=39870/16/63
Timing buffered disk reads: 64 MB in 1.81 seconds = 35.36 MB/sec
athy:~ # hdparm -it /dev/hda
/dev/hda:
Model=IBM-DTLA-307075, FwRev=TXAOA50C, SerialNo=YSDYSFA5874
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=150136560
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
Drive Supports : Reserved : ATA-2 ATA-3 ATA-4 ATA-5
Kernel Drive Geometry LogicalCHS=9345/255/63 PhysicalCHS=148945/16/63
Timing buffered disk reads: 64 MB in 1.78 seconds = 35.96 MB/sec
Just because you can not configure your kernel correctly of have junk for
hardware or any other lame reason like a distro that does not know what
dma is..your problem not mine.
General bitching pisses me off, especially when you are dead wrong.
Regards,
Andre Hedrick
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Abysmal RECV network performance
>From: Nivedita Singhvi <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>CC: [EMAIL PROTECTED]
>Subject: Re: Abysmal RECV network performance
>Date: Mon, 28 May 2001 23:45:28 -0700 (PDT)
>While we didnt use 2.2 kernels at all, we did similar tests
>on 2.4.0 through 2.4.4 kernels, on UP and SMP. I've used
>a similar machine (PII 333MHz) as well as faster (866MHz)
>machines, and got pretty nifty (> 90Mbs) throughput on
>netperf tests (tcp stream, no disk I/O) over a 100Mb full
>duplex link. (not sure if there are any P-90 issues).
>
>Throughput does drop with small MTU, very small packet sizes,
>small socket buffer sizes, but only at extremes, for the most
>part throughput was well over 70Mbs. (this is true for single
>connections, you dont mention how many connections you were
>scaling to, if any).
Sorry, yes - I was doing single connection tests with no changes to the
default Netperf settings. Each machine was running a copy of the server and
then I ran the test with "netperf -H x.x.x.x" to each machine (or just
"netperf" for a localhost speed check).
>However, we did run into serious performance problems with
>the Netgear FA311/2 (tulip). Found that the link lost
>connectivity because of card lockups and transmit timeout
>failures - and some of these were silent. However, I moved
>to the 3C905C (3c59x driver) which behaved like a champ, and
>we didnt see the problems any more, so have stuck to that card.
>This was back in the 2.4.0 time frame, and there have many
>patches since then to various drivers, so not sure if the
>problem(s) have been resolved or not (likely to have been,
>extensively reported). Both your cards might actually be
>underperforming..
I'm a little confused here - do you mean the FA310TX ("tulip" driver) or the
FA311/2 ("natsemi" driver)? I have not had any connection problems with
either the FA310 or the FA311 cards. I haven't noticed any speed problems
with the FA311 card, but I haven't benchmarked it, either. The FA310 is so
horribly slow, I couldn't help but notice. Unfortunately, the same is true
of the 3cSOHO.
While I am willing to accept that both the FA310 and FA311 cards are
underperforming, I think it is more than a little strange that the 3cSOHO
card would turn in the same performance numbers. Also, keep in mind that I
was only seeing horrible receive performance, TX performance seemed to be
ok.
I didn't post FTP numbers (both machines are running FTP servers). While the
FTP performance numbers are probably not as "scientific" as Netperf, they do
seem to agree from what I have observered. I.e. retrieving files from the
P-90 machine is ok (~3MB/sec) but sending files to it is very slow
(~100K/sec). This roughly agrees with the Netperf numbers I saw.
FTP transfers to the FA311 machine (P2-350) are OK in both directions.
>Are you seeing any errors reported in /var/log/messages?
>Are you monitoring your connection via tcpdump, for example?
>You might sometimes see long gaps in transmission...Are
>there any abnormal numbers in /proc/net/ stats? I dont remember
>seeing that high frame errors, although there were a few.
No, I don't see anything in /var/log/messages.
I looked at tcpdump to try and figure it out, and it appeared that the P-90
was taking a very long time to ACK some packets. I am not a TCP/IP guru by
any stretch, but my guess at the time was that the packets that were taking
forever to get ACK'ed were the ones causing a framing error on the P-90, but
again, I'm not an expert.
The only unusual stat is the framing errors. There are a lot of them under
heavy receive load. The machine will go for weeks without a single framing
error, but if I blast some netperf action at it (or FTP send to it, etc.)
then I get about 1/3 of the incoming packets (to the P-90) with framing
errors. I see no other errors at all except a TX overrun error (maybe 1 in
10 packets).
>HW checksumming for the kind of test you are doing (tcp, mostly
>fast path) will not buy you any real performance gain, the
>checksum is actually consumed by the user-kernel copy routine.
Ok, I'll take your word for it. The P-90 isn't a very fast machine to begin
with, so I thought it could use all the HW assistance it could get (that and
the 3cSOHO card was really cheap :-).
I am very disappointed that TCP/IP performance on this machine is so lousy,
but the problem is clearly with the kernel - just look at the performance
numbers for 2.4.3 vs 2.2.19 (or 2.2.16). Those numbers aren't exactly great,
but they are a lot better than 2.4.3.
>You can also run the tests on a profiling kernel and compare
>results...
>
>Nivedita
>
>---
>Nivedita Singhvi(503) 578-4580
>Linux Technology Center [EMAIL PROTECTED]
>IBM Beaverton, OR [EMAIL PROTECTED]
Thanks for the assistance. Based on the benchmark information I have, I
would say that there is a problem with the kernel and would like to pursue
getting that fixed. I just
Re: 2.4.5-ac3: qlogic corruption on alpha
On Tue, May 29, 2001 at 10:05:27PM -0400, Jeff Garzik wrote: > Also, what compiler are you using? Depending on your current compiler, > switching to another compiler according to one of the following > permutations would be very instructive for us debugging the problem, at > least. debian 2.25.2 2220 > gcc-2.96-RH -> gcc-2.95.3 > gcc-2.95.2 -> gcc-2.95.3 > gcc-2.95.3 -> egcs-1.1.2 i'll give another one a try, tomorrow. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5-ac3: qlogic corruption on alpha
On Tue, May 29, 2001 at 09:17:45PM -0400, Jeff Garzik wrote: > Tom Vier wrote: > > i narrowed down some corruption i was having. it only happens on drives > > attached to my qlogic isp card. 2.2 has no problem, and in 2.4.5-ac3 my > > sym53c875 works fine. this machine is an alpha miata. it only happens when > > writing out a lot to disk. eg, untarring a kernel tarball, restoring a > > backup. anyone else see this? > > Is this reproducible? yes. by restoring a backup from tape. i tried cat /dev/zero > /dev/sdb1, but that wasn't enough to trigger any corruption (i correctly wrote all zeros). actually, now that i think about it, a good chunk of /dev/sdb2 was cached when i read it back, so that wasn't a very good test. i definetly get corruption under 2.4.5-ac4. > Other questions - is your machine SMP? How much RAM? UP, half gig. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net #9
On Tue, May 29, 2001 at 10:13:02PM -0400, Jeff Garzik wrote: > *shrug* Well, if you want to go against the kernel standard that's fine > with me. I won't put Andrzej's changes to your drivers upstream. You > are going to continually see patches to clean that up, though, because > it makes the end user's kernel smaller. Please consider noting this > special case in a comment in each of your drivers "do not clean up > static initializers" or similar. > > It's really a pain in the ass to remember special cases like this, so > please reconsider. Being not-like-the-others is detrimental to the long > term maintainability of the overall kernel. > > Regards, > > Jeff I agree with you on the special case. I don't like it either. Anyway, most patch to my drivers are applied wether I like it or not, so I guess that I should be happy that I was notified and I should sut up my big mouth because it won't make a difference. If I reject the patch now, I will be applied behind my back. Been there, done that. In other words : yes, please apply the patch. Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net #9
On Tue, May 29, 2001 at 09:47:19PM -0400, Jeff Garzik wrote: > > This is ANSI C standard stuff. If a static object with a scalar type is > not explicitly initialized, it is initialized to zero by default. > > Sure we can get gcc to recognize that case, but why use gcc to work > around code that avoids an ANSI feature? Apart from this stupid flame that I'm making, I've got my Intel/Symbol card to work properly with the Orinoco driver. This mean that we are not far away to have the 4 main flavor of 802.11b working in 2.4.X (i.e. Lucent/Symbol/PrismII/Aironet). See : http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Orinoco.html#patches Just to make sure we end on a positive note ;-) Now, if I could get the card of Alan to work... Have fun, don't take it seriously... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5-ac3: qlogic corruption on alpha
Tom Vier wrote: > > i narrowed down some corruption i was having. it only happens on drives > attached to my qlogic isp card. 2.2 has no problem, and in 2.4.5-ac3 my > sym53c875 works fine. this machine is an alpha miata. it only happens when > writing out a lot to disk. eg, untarring a kernel tarball, restoring a > backup. anyone else see this? Also, what compiler are you using? Depending on your current compiler, switching to another compiler according to one of the following permutations would be very instructive for us debugging the problem, at least. gcc-2.96-RH -> gcc-2.95.3 gcc-2.95.2 -> gcc-2.95.3 gcc-2.95.3 -> egcs-1.1.2 Regards, Jeff -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac4 es1371.o unresolved symbols
Hello, While 'make modules_install' on 2.4.5-ac4, I received the following error: depmod: *** Unresolved symbols in /lib/modules/2.4.5-ac4/kernel/drivers/sound/es1371.o depmod: gameport_register_port_Rsmp_aa96bd99 depmod: gameport_unregister_port_Rsmp_ec101047 The previous steps make mrproper, make config, make clean, make bzImage, make modules all appeared to work. The .config is the same as 2.4.5-ac3 Regards, Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net #9
Jean Tourrilhes wrote: > > On Tue, May 29, 2001 at 09:13:34PM -0400, Jeff Garzik wrote: > > > > This is standard kernel cleanup that makes the resulting image smaller. > > These patches have been going into all areas of the kernel for quite > > some time. > > This doesn't make it right. > > Ok, while we are on the topic : could somebody explain me why > we can't get gcc to do that for us ? What is preventing adding a gcc > command line flag to do exactly that ? It's not like rocket science > (simple test) and would avoid to have tediously to go through all > source code, past, present and *future* to make those changes. > Bah, maybe it's too straightforward... This is ANSI C standard stuff. If a static object with a scalar type is not explicitly initialized, it is initialized to zero by default. Sure we can get gcc to recognize that case, but why use gcc to work around code that avoids an ANSI feature? -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel 2.2: tq_scheduler functions scheduling and waiting
I have tested with a kernel thread running the tq_scheduler and it is much more stable. The kernel still ran into a problem in n_tty.c in which the compiler optimized-out the check "if (!tty)" in n_tty_set_termios(); I am still investigating the right solution to this. As a long term fix, I will review the 2.4 and latest 2.2 sources. > Yes. The situation where one task is on two waitqueues > is rare, but does happen. And yes, there is code out there > which does a bare schedule() and *assumes* that once the > schedule has returned, the thing it was waiting for has > indeed occurred. > > Generally this is poor practice - it's safer to loop > over the schedule() call until the condition you're > sleeping on has been tested. I see your point. It would prevent this type of problem if all code waiting for conditions made certain those conditions were met. However, given the way the kernel works, it is not necessary to check unless the task specifically expects more than one condition to awaken it - at least it wasn't until tq_scheduler was introduced. Actually, that is not fair either - only when functions in tq_scheduler starting "blocking" did this become a problem. It would help me tremendously if these types of limitations and requirements for working in the kernel were well documented. It takes significant effort to determine the requirements, and to verify that my understanding is correct. > > You really shouldn't be sleeping in this way on tq_scheduler > if there's any way in which the sleep can take an extended > period of time. You may end up putting important kernel > tasks to sleep. I agree. In addition, even if the tq_scheduler function did check for its own condition, a problem still exists when the task returns to the code using the first wait queue before its condition is met; since the code using the second wait queue would set the task state to running and would not set it back (which it couldn't without knowing the conditions to check). > > Best to use schedule_task(), or an independent kernel thread. > > - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net #9
On Tue, May 29, 2001 at 09:13:34PM -0400, Jeff Garzik wrote: > > This is standard kernel cleanup that makes the resulting image smaller. > These patches have been going into all areas of the kernel for quite > some time. This doesn't make it right. Ok, while we are on the topic : could somebody explain me why we can't get gcc to do that for us ? What is preventing adding a gcc command line flag to do exactly that ? It's not like rocket science (simple test) and would avoid to have tediously to go through all source code, past, present and *future* to make those changes. Bah, maybe it's too straightforward... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Emulate RDTSC
Hi all, What is the nice way (in accuracy and performance) to emulate RDTSC in Linux for those architectures who dont support RDTSC like in Hitachi SH Processors. Thank you, Best Regards, Jaswinder. -- These are my opinions not 3Di. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5-ac3: qlogic corruption on alpha
Tom Vier wrote: > i narrowed down some corruption i was having. it only happens on drives > attached to my qlogic isp card. 2.2 has no problem, and in 2.4.5-ac3 my > sym53c875 works fine. this machine is an alpha miata. it only happens when > writing out a lot to disk. eg, untarring a kernel tarball, restoring a > backup. anyone else see this? Is this reproducible? A patch went into ac3 which attempts to address qlogicisp problems on Alpha. It originated from the nether regions deep inside Compaq, original source unknown. There is a -extraordinarily slight- possibility this patch (which simply adds "mb()") causes problems. However, it is more likely that the patch is harmless but also useless, not fixing the real problem. Other questions - is your machine SMP? How much RAM? -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac3: qlogic corruption on alpha
i narrowed down some corruption i was having. it only happens on drives attached to my qlogic isp card. 2.2 has no problem, and in 2.4.5-ac3 my sym53c875 works fine. this machine is an alpha miata. it only happens when writing out a lot to disk. eg, untarring a kernel tarball, restoring a backup. anyone else see this? -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net #9
On Wed, May 30, 2001 at 02:48:24AM +0200, Andrzej Krzysztofowicz wrote: > > The following patch removes some zero initializers from statics > > Andrzej If I were you, I would fix gcc rather than making my code unreadable. I write source code in C rather than coding ASM in hex because of the semantic attached to what I write, which make the code readable by me and by other, and make my code portable to other environments (for example user space). Initialisating a variable to zero as opposed to leaving it undefined has plenty of semantic attached to it. It's the job of the compiler to make sure that all this kind of stupid optimisation are done and the code produced is as efficient as possible and adapted to the exact characteristics of the operating envirtonment. Especially that it's probably 10 lines to add the proper option to gcc command line. Therefore, Alan, please do not apply those kind of patches to my drivers. Thanks... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net #1 (correction)
Sorry, one fix against previous patch Andrzej --- drivers/net/wavelan.p.h~Wed May 30 02:43:16 2001 +++ drivers/net/wavelan.p.h Wed May 30 02:44:29 2001 @@ -705,9 +705,9 @@ MODULE_PARM(io, "1-4i"); MODULE_PARM(irq, "1-4i"); MODULE_PARM(name, "1-4c" __MODULE_STRING(IFNAMSIZ)); -MODULE_PARM(io, "WaveLAN I/O base address(es),required"); -MODULE_PARM(irq, "WaveLAN IRQ number(s)"); -MODULE_PARM(name, "WaveLAN interface neme(s)"); +MODULE_PARM_DESC(io, "WaveLAN I/O base address(es),required"); +MODULE_PARM_DESC(irq, "WaveLAN IRQ number(s)"); +MODULE_PARM_DESC(name, "WaveLAN interface neme(s)"); #endif /* MODULE */ #endif /* WAVELAN_P_H */ -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net #8
The following patch fixes some bogus comments in /drivers/net/*.c Andrzej *** PATCH 8 * diff -uNr linux-2.4.5-ac4/drivers/net/3c501.c linux/drivers/net/3c501.c --- linux-2.4.5-ac4/drivers/net/3c501.c Wed May 30 01:09:52 2001 +++ linux/drivers/net/3c501.c Wed May 30 01:15:20 2001 @@ -253,7 +253,7 @@ } /** - * el1_probe: + * el1_probe1: * @dev: The device structure to use * @ioaddr: An I/O address to probe at. * diff -uNr linux-2.4.5-ac4/drivers/net/aironet4500_proc.c linux/drivers/net/aironet4500_proc.c --- linux-2.4.5-ac4/drivers/net/aironet4500_proc.c Tue May 29 20:46:26 2001 +++ linux/drivers/net/aironet4500_proc.cWed May 30 01:15:20 2001 @@ -1,5 +1,5 @@ /* - * Aironet 4500 Pcmcia driver + * Aironet 4500 /proc interface * * Elmer Joandi, Januar 1999 * Copyright GPL diff -uNr linux-2.4.5-ac4/drivers/net/bagetlance.c linux/drivers/net/bagetlance.c --- linux-2.4.5-ac4/drivers/net/bagetlance.cWed May 30 01:08:54 2001 +++ linux/drivers/net/bagetlance.c Wed May 30 01:15:20 2001 @@ -1,5 +1,5 @@ /* $Id$ - * vmelance.c: Ethernet driver for VME Lance cards on Baget/MIPS + * bagetlance.c: Ethernet driver for VME Lance cards on Baget/MIPS * This code stealed and adopted from linux/drivers/net/atarilance.c * See that for author info * diff -uNr linux-2.4.5-ac4/drivers/net/seeq8005.c linux/drivers/net/seeq8005.c --- linux-2.4.5-ac4/drivers/net/seeq8005.c Wed May 30 01:08:55 2001 +++ linux/drivers/net/seeq8005.cWed May 30 01:15:20 2001 @@ -101,8 +101,6 @@ /* Check for a network adaptor of this type, and return '0' iff one exists. If dev->base_addr == 0, probe all likely locations. If dev->base_addr == 1, always return failure. - If dev->base_addr == 2, allocate space for the device and return success - (detachable devices only). */ int __init diff -uNr linux-2.4.5-ac4/drivers/net/sk_g16.c linux/drivers/net/sk_g16.c --- linux-2.4.5-ac4/drivers/net/sk_g16.cMon May 28 01:34:55 2001 +++ linux/drivers/net/sk_g16.c Wed May 30 01:15:20 2001 @@ -536,8 +536,6 @@ * Check for a network adaptor of this type, and return '0' if one exists. * If dev->base_addr == 0, probe all likely locations. * If dev->base_addr == 1, always return failure. - * If dev->base_addr == 2, allocate space for the device and return success - * (detachable devices only). */ int __init SK_init(struct net_device *dev) diff -uNr linux-2.4.5-ac4/drivers/net/winbond-840.c linux/drivers/net/winbond-840.c --- linux-2.4.5-ac4/drivers/net/winbond-840.c Wed May 30 01:08:56 2001 +++ linux/drivers/net/winbond-840.c Wed May 30 01:15:20 2001 @@ -1,4 +1,4 @@ -/* winbond-840.c: A Linux PCI network adapter skeleton device driver. */ +/* winbond-840.c: A Linux PCI network adapter device driver. */ /* Written 1998-2001 by Donald Becker. -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net #5
The following patch fixes some long udelay()s in aironet.c and saa9730.c
in the current kernel tree.
Andrzej
*** PATCH 5 ***
diff -uNr linux-2.4.5-ac4/drivers/net/aironet4500_card.c
linux/drivers/net/aironet4500_card.c
--- linux-2.4.5-ac4/drivers/net/aironet4500_card.c Mon May 28 01:34:54 2001
+++ linux/drivers/net/aironet4500_card.cWed May 30 01:12:57 2001
@@ -723,14 +723,14 @@
awc_i365_card_release(s);
- udelay(10);
+ mdelay(100);
i365_out(s, 0x2, 0x10 );// power enable
- udelay(20);
+ mdelay(200);
i365_out(s, 0x2, 0x10 | 0x01 | 0x04 | 0x80);//power enable
- udelay(25);
+ mdelay(250);
if (!s->irq)
s->irq = 11;
@@ -756,7 +756,7 @@
i365_out(s,0x15,0x3f | 0x40); // enab mem reg bit
i365_out(s,0x06,0x01); // enab mem
- udelay(1);
+ mdelay(10);
cis[0] = 0x45;
@@ -767,7 +767,7 @@
mem[0x3e0] = 0x45;
- udelay(1);
+ mdelay(10);
memcpy_fromio(cis,0xD000, 0x3e0);
@@ -795,7 +795,7 @@
s->socket, s->manufacturer,s->product);
i365_out(s,0x07, 0x1 | 0x2);// enable io 16bit
- udelay(1000);
+ mdelay(1);
port = s->io;
i365_out(s,0x08, port & 0xff);
i365_out(s,0x09, (port & 0xff00)/ 0x100);
@@ -804,7 +804,7 @@
i365_out(s,0x06, 0x40); // enable io window
- udelay(1000);
+ mdelay(1);
i365_out(s,0x3e0,0x45);
@@ -822,13 +822,10 @@
outw(0x10, s->io + 0x34);
- udelay(1);
+ mdelay(10);
return 0;
-
-
-
};
diff -uNr linux-2.4.5-ac4/drivers/net/saa9730.c linux/drivers/net/saa9730.c
--- linux-2.4.5-ac4/drivers/net/saa9730.c Sat May 19 18:35:48 2001
+++ linux/drivers/net/saa9730.c Wed May 30 01:12:57 2001
@@ -335,7 +335,7 @@
printk("Error: lan_saa9730_mii_init: timeout\n");
return -1;
}
- udelay(1000); /* wait 1 ms. */
+ mdelay(1); /* wait 1 ms. */
}
/* Now set the control and address register. */
@@ -350,11 +350,11 @@
printk("Error: lan_saa9730_mii_init: timeout\n");
return -1;
}
- udelay(1000); /* wait 1 ms. */
+ mdelay(1); /* wait 1 ms. */
}
/* Wait for 1 ms. */
- udelay(1000);
+ mdelay(1);
/* Check the link status. */
if (INL(>lan_saa9730_regs->StationMgmtData) &
@@ -369,7 +369,7 @@
>lan_saa9730_regs->StationMgmtCtl);
/* Wait for 1 ms. */
- udelay(1000);
+ mdelay(1);
/* set 'CONTROL' = force reset and renegotiate */
OUTL(PHY_CONTROL_RESET | PHY_CONTROL_AUTO_NEG |
@@ -377,7 +377,7 @@
>lan_saa9730_regs->StationMgmtData);
/* Wait for 50 ms. */
- udelay(50 * 1000);
+ mdelay(50);
/* set 'BUSY' to start operation */
OUTL(MD_CA_BUSY | PHY_ADDRESS << MD_CA_PHY_SHF | MD_CA_WR |
@@ -393,11 +393,11 @@
("Error: lan_saa9730_mii_init: timeout\n");
return -1;
}
- udelay(1000); /* wait 1 ms. */
+ mdelay(1); /* wait 1 ms. */
}
/* Wait for 1 ms. */
- udelay(1000);
+ mdelay(1);
for (l = 0; l < 2; l++) {
/* set PHY address = 'STATUS' */
@@ -415,11 +415,11 @@
("Error: lan_saa9730_mii_init: timeout\n");
return -1;
}
- udelay(1000); /* wait 1 ms. */
+ mdelay(1); /* wait 1 ms. */
}
/* wait for 3 sec. */
- udelay(3000 * 1000);
+ mdelay(3000);
/* check the link status */
if (INL(>lan_saa9730_regs->StationMgmtData) &
@@ -495,7 +495,7 @@
("Error: lan_sa9730_stop: MAC reset timeout\n");
return -1;
}
- udelay(1000); /* wait 1 ms. */
+ mdelay(1); /* wait 1 ms. */
}
return 0;
--
===
Andrzej M. Krzysztofowicz [EMAIL PROTECTED]
phone (48)(58) 347 14 61
[PATCH] net #9
The following patch removes some zero initializers from statics
Andrzej
PATCH 9 *
diff -uNr linux-2.4.5-ac4/drivers/net/dmfe.c linux/drivers/net/dmfe.c
--- linux-2.4.5-ac4/drivers/net/dmfe.c Wed May 30 01:08:54 2001
+++ linux/drivers/net/dmfe.cWed May 30 01:16:04 2001
@@ -261,20 +261,20 @@
static char version[] __devinitdata =
KERN_INFO "Davicom DM9xxx net driver, version " DMFE_VERSION "\n";
-static int dmfe_debug = 0;
+static int dmfe_debug;
static unsigned char dmfe_media_mode = DMFE_AUTO;
-static u32 dmfe_cr6_user_set = 0;
+static u32 dmfe_cr6_user_set;
/* For module input parameter */
-static int debug = 0;
-static u32 cr6set = 0;
+static int debug;
+static u32 cr6set;
static unsigned char mode = 8;
static u8 chkmode = 1;
-static u8 HPNA_mode = 0; /* Default: Low Power/High Speed */
-static u8 HPNA_rx_cmd = 0; /* Default: Disable Rx remote command */
-static u8 HPNA_tx_cmd = 0; /* Default: Don't issue remote command */
-static u8 HPNA_NoiseFloor = 0; /* Default: HPNA NoiseFloor */
-static u8 SF_mode = 0; /* Special Function: 1:VLAN, 2:RX Flow Control
+static u8 HPNA_mode; /* Default: Low Power/High Speed */
+static u8 HPNA_rx_cmd; /* Default: Disable Rx remote command */
+static u8 HPNA_tx_cmd; /* Default: Don't issue remote command */
+static u8 HPNA_NoiseFloor; /* Default: HPNA NoiseFloor */
+static u8 SF_mode; /* Special Function: 1:VLAN, 2:RX Flow Control
4: TX pause packet */
unsigned long CrcTable[256] = {
diff -uNr linux-2.4.5-ac4/drivers/net/wavelan.p.h linux/drivers/net/wavelan.p.h
--- linux-2.4.5-ac4/drivers/net/wavelan.p.h Wed May 30 01:08:56 2001
+++ linux/drivers/net/wavelan.p.h Wed May 30 01:16:05 2001
@@ -699,9 +699,9 @@
#ifdef MODULE
/* Parameters set by insmod */
-static int io[4] = { 0, 0, 0, 0 };
-static int irq[4] = { 0, 0, 0, 0 };
-static charname[4][IFNAMSIZ] = { "", "", "", "" };
+static int io[4];
+static int irq[4];
+static charname[4][IFNAMSIZ];
MODULE_PARM(io, "1-4i");
MODULE_PARM(irq, "1-4i");
MODULE_PARM(name, "1-4c" __MODULE_STRING(IFNAMSIZ));
--
===
Andrzej M. Krzysztofowicz [EMAIL PROTECTED]
phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math., Technical University of Gdansk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net #4
The following patch fixes network drivers configuration in some points: - make sb1000 dependent on CONFIG_ISAPNP. It compiles without CONFIG_ISAPNP, but will not work as the driver relies on ISA PnP board detection - de620 does not support build-in configuration (dependency on "m" now). It compiles, but requires io/irq module parameters for board detection (even ether= is not supported by this driver) - Aironet fixes: -- Aironet PnP requires CONFIG_ISAPNP (y or m) to work; of course, when CONFIG_ISAPNP=m CONFIG_AIRONET4500_NONCS also should be "m", but this is not supported by CML1; to be fixed in CML2 or in another way -- Aironet I365 and ISA detection for built-in driver is not supported currently, so disable these options if CONFIG_AIRONET4500_NONCS=y Andrzej * PATCH 5 *** diff -uNr linux-2.4.5-ac4/drivers/net/Config.in linux/drivers/net/Config.in --- linux-2.4.5-ac4/drivers/net/Config.in Mon May 28 01:34:54 2001 +++ linux/drivers/net/Config.in Wed May 30 01:11:56 2001 @@ -15,7 +15,7 @@ fi fi -tristate 'General Instruments Surfboard 1000' CONFIG_NET_SB1000 +dep_tristate 'General Instruments Surfboard 1000' CONFIG_NET_SB1000 $CONFIG_ISAPNP # # Ethernet @@ -180,7 +180,7 @@ if [ "$CONFIG_NET_POCKET" = "y" ]; then dep_tristate 'AT-LAN-TEC/RealTek pocket adapter support' CONFIG_ATP $CONFIG_ISA tristate 'D-Link DE600 pocket adapter support' CONFIG_DE600 - tristate 'D-Link DE620 pocket adapter support' CONFIG_DE620 + dep_tristate 'D-Link DE620 pocket adapter support' CONFIG_DE620 m fi fi @@ -264,10 +264,14 @@ tristate ' Aironet 4500/4800 series adapters' CONFIG_AIRONET4500 dep_tristate ' Aironet 4500/4800 ISA/PCI/PNP/365 support ' CONFIG_AIRONET4500_NONCS $CONFIG_AIRONET4500 if [ "$CONFIG_AIRONET4500" != "n" -a "$CONFIG_AIRONET4500_NONCS" != "n" ]; then - bool ' Aironet 4500/4800 PNP support ' CONFIG_AIRONET4500_PNP + if [ "$CONFIG_AIRONET4500_NONCS" = "m" -a "$CONFIG_ISAPNP" = "m" -o +"$CONFIG_ISAPNP" = "y" ]; then +bool ' Aironet 4500/4800 PNP support ' CONFIG_AIRONET4500_PNP + fi dep_bool ' Aironet 4500/4800 PCI support ' CONFIG_AIRONET4500_PCI $CONFIG_PCI - dep_bool ' Aironet 4500/4800 ISA broken support (EXPERIMENTAL)' CONFIG_AIRONET4500_ISA $CONFIG_EXPERIMENTAL - dep_bool ' Aironet 4500/4800 I365 broken support (EXPERIMENTAL)' CONFIG_AIRONET4500_I365 $CONFIG_EXPERIMENTAL + if [ "$CONFIG_AIRONET4500_NONCS" = "m" ]; then +dep_bool ' Aironet 4500/4800 ISA broken support (EXPERIMENTAL)' +CONFIG_AIRONET4500_ISA $CONFIG_EXPERIMENTAL +dep_bool ' Aironet 4500/4800 I365 broken support (EXPERIMENTAL)' +CONFIG_AIRONET4500_I365 $CONFIG_EXPERIMENTAL + fi fi dep_tristate ' Aironet 4500/4800 PROC interface ' CONFIG_AIRONET4500_PROC $CONFIG_AIRONET4500 m -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net #6
The following patch removes unnecessary #ifdefs from eexpress.c
Andrzej
** PATCH 6 ***
diff -uNr linux-2.4.5-ac4/drivers/net/eexpress.c linux/drivers/net/eexpress.c
--- linux-2.4.5-ac4/drivers/net/eexpress.c Wed May 30 01:08:54 2001
+++ linux/drivers/net/eexpress.cWed May 30 01:13:49 2001
@@ -574,9 +574,7 @@
static void eexp_timeout(struct net_device *dev)
{
struct net_local *lp = (struct net_local *)dev->priv;
-#ifdef CONFIG_SMP
- unsigned long flags;
-#endif
+ unsigned long __attribute__((unused)) flags;
int status;
disable_irq(dev->irq);
@@ -586,10 +584,7 @@
* lets make it work first..
*/
-#ifdef CONFIG_SMP
spin_lock_irqsave(>lock, flags);
-#endif
-
status = scb_status(dev);
unstick_cu(dev);
printk(KERN_INFO "%s: transmit timed out, %s?\n", dev->name,
@@ -602,9 +597,7 @@
outb(0,dev->base_addr+SIGNAL_CA);
}
netif_wake_queue(dev);
-#ifdef CONFIG_SMP
spin_unlock_irqrestore(>lock, flags);
-#endif
}
/*
@@ -614,9 +607,7 @@
static int eexp_xmit(struct sk_buff *buf, struct net_device *dev)
{
struct net_local *lp = (struct net_local *)dev->priv;
-#ifdef CONFIG_SMP
- unsigned long flags;
-#endif
+ unsigned long __attribute__((unused)) flags;
#if NET_DEBUG > 6
printk(KERN_DEBUG "%s: eexp_xmit()\n", dev->name);
@@ -629,10 +620,7 @@
* lets make it work first..
*/
-#ifdef CONFIG_SMP
spin_lock_irqsave(>lock, flags);
-#endif
-
{
unsigned short length = (ETH_ZLEN < buf->len) ? buf->len :
ETH_ZLEN;
@@ -643,9 +631,7 @@
eexp_hw_tx_pio(dev,data,length);
}
dev_kfree_skb(buf);
-#ifdef CONFIG_SMP
spin_unlock_irqrestore(>lock, flags);
-#endif
enable_irq(dev->irq);
return 0;
}
--
===
Andrzej M. Krzysztofowicz [EMAIL PROTECTED]
phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math., Technical University of Gdansk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net #1
>From kufel!ankry Wed May 30 02:29:36 2001
Return-Path:
Received: from kufel.UUCP (uucp@localhost)
by green.mif.pg.gda.pl (8.9.3/8.9.3) with UUCP id CAA04405
for green.mif.pg.gda.pl!ankry; Wed, 30 May 2001 02:29:35 +0200
Received: (from ankry@localhost)
by kufel.dom (8.9.3/8.9.3) id CAA02200
for green!ankry; Wed, 30 May 2001 02:07:43 +0200
Date: Wed, 30 May 2001 02:07:43 +0200
From: Andrzej Krzysztofowicz
Message-Id: <[EMAIL PROTECTED]>
To: kufel!green.mif.pg.gda.pl!ankry
Subject: alan.1
cox, jg, [EMAIL PROTECTED], [EMAIL PROTECTED]
Hi,
This patch adds MODULE_PARM_DESC to all drivers located directly in
drivers/net. Some existing descriptions are fixed; some undefined
parameters are disabled.
Also a dependency of 3c509 parameters on CONFIG_ISAPNP is removed. It is
better to have a non-working parameter (many drivers have such parameters)
than having a driver that sometimes supports a parameter and sometimes it
does not...
This is the first of my series of network patches, that are generated
incrementally against 2.4.5-ac4. However, they are so separated, that
can be applied independently (eventually with some minor shifts)
Andrzej
*** PATCH 1 *
diff -uNr linux-2.4.5-ac4/drivers/net/3c501.c linux/drivers/net/3c501.c
--- linux-2.4.5-ac4/drivers/net/3c501.c Sat May 19 18:35:42 2001
+++ linux/drivers/net/3c501.c Wed May 30 01:07:41 2001
@@ -925,6 +925,8 @@
static int irq=5;
MODULE_PARM(io, "i");
MODULE_PARM(irq, "i");
+MODULE_PARM_DESC(io, "EtherLink I/O base address");
+MODULE_PARM_DESC(irq, "EtherLink IRQ number");
/**
* init_module:
diff -uNr linux-2.4.5-ac4/drivers/net/3c503.c linux/drivers/net/3c503.c
--- linux-2.4.5-ac4/drivers/net/3c503.c Sat May 19 18:35:42 2001
+++ linux/drivers/net/3c503.c Wed May 30 01:07:41 2001
@@ -615,6 +615,9 @@
MODULE_PARM(io, "1-" __MODULE_STRING(MAX_EL2_CARDS) "i");
MODULE_PARM(irq, "1-" __MODULE_STRING(MAX_EL2_CARDS) "i");
MODULE_PARM(xcvr, "1-" __MODULE_STRING(MAX_EL2_CARDS) "i");
+MODULE_PARM_DESC(io, "EtherLink II I/O base address(es)");
+MODULE_PARM_DESC(irq, "EtherLink II IRQ number(s) (assigned)");
+MODULE_PARM_DESC(xcvr, "EtherLink II tranceiver(s) (0=internal, 1=external)");
/* This is set up so that only a single autoprobe takes place per call.
ISA device autoprobes on a running machine are not recommended. */
diff -uNr linux-2.4.5-ac4/drivers/net/3c505.c linux/drivers/net/3c505.c
--- linux-2.4.5-ac4/drivers/net/3c505.c Sat May 19 18:35:42 2001
+++ linux/drivers/net/3c505.c Wed May 30 01:07:41 2001
@@ -1621,6 +1621,9 @@
MODULE_PARM(io, "1-" __MODULE_STRING(ELP_MAX_CARDS) "i");
MODULE_PARM(irq, "1-" __MODULE_STRING(ELP_MAX_CARDS) "i");
MODULE_PARM(dma, "1-" __MODULE_STRING(ELP_MAX_CARDS) "i");
+MODULE_PARM_DESC(io, "EtherLink Plus I/O base address(es)");
+MODULE_PARM_DESC(irq, "EtherLink Plus IRQ number(s) (assigned)");
+MODULE_PARM_DESC(dma, "EtherLink Plus DMA channel(s)");
int init_module(void)
{
diff -uNr linux-2.4.5-ac4/drivers/net/3c507.c linux/drivers/net/3c507.c
--- linux-2.4.5-ac4/drivers/net/3c507.c Sat May 19 18:35:42 2001
+++ linux/drivers/net/3c507.c Wed May 30 01:07:41 2001
@@ -861,6 +861,8 @@
static int irq;
MODULE_PARM(io, "i");
MODULE_PARM(irq, "i");
+MODULE_PARM_DESC(io, "EtherLink16 I/O base address");
+MODULE_PARM_DESC(irq, "(ignored)");
int init_module(void)
{
diff -uNr linux-2.4.5-ac4/drivers/net/3c509.c linux/drivers/net/3c509.c
--- linux-2.4.5-ac4/drivers/net/3c509.c Sat May 19 18:35:42 2001
+++ linux/drivers/net/3c509.c Wed May 30 01:07:41 2001
@@ -1007,9 +1007,12 @@
MODULE_PARM(irq,"1-8i");
MODULE_PARM(xcvr,"1-8i");
MODULE_PARM(max_interrupt_work, "i");
-#ifdef CONFIG_ISAPNP
+MODULE_PARM_DESC(debug, "EtherLink III debug level (0-6)");
+MODULE_PARM_DESC(irq, "EtherLink III IRQ number(s) (assigned)");
+MODULE_PARM_DESC(xcvr,"EtherLink III tranceiver(s) (0=internal, 1=external)");
+MODULE_PARM_DESC(max_interrupt_work, "EtherLink III maximum events handled per
+interrupt");
MODULE_PARM(nopnp, "i");
-#endif
+MODULE_PARM_DESC(nopnp, "EtherLink III disable ISA PnP support (0-1)");
int
init_module(void)
diff -uNr linux-2.4.5-ac4/drivers/net/3c515.c linux/drivers/net/3c515.c
--- linux-2.4.5-ac4/drivers/net/3c515.c Sat May 19 18:35:42 2001
+++ linux/drivers/net/3c515.c Wed May 30 01:07:41 2001
@@ -85,6 +85,11 @@
MODULE_PARM(full_duplex, "1-" __MODULE_STRING(8) "i");
MODULE_PARM(rx_copybreak, "i");
MODULE_PARM(max_interrupt_work, "i");
+MODULE_PARM_DESC(debug, "3c515 debug level (0-6)");
+MODULE_PARM_DESC(options, "3c515: Bits 0-2: media type, bit 3: full duplex, bit 4:
+bus mastering");
+MODULE_PARM_DESC(full_duplex, "(ignored)");
+MODULE_PARM_DESC(rx_copybreak, "3c515 copy breakpoint for copy-only-tiny-frames");
+MODULE_PARM_DESC(max_interrupt_work, "3c515 maximum events handled per interrupt");
/* "Knobs" for adjusting internal parameters. */
/* Put out somewhat more debugging messages. (0 - no
Re: 2.4 freezes on VIA KT133 -- mine FIXED
Mark Hahn wrote: > > > contrary to the implication here, I don't believe there is any *general* > > > problem with Linux/VIA/AMD stability. there are well-known issues > ... > > VIA hardware is not suitable for anything until we _know_ the > > truth about what is wrong. VIA is hiding something big. > afaik, there are absolutely zero problems reported with kt133-no-a > machines, for instance. mine has certainly worked flawlessly for a > long time, on most every 2.3/2.4 kernel over the past year+. FWIW, I'm shaking down a 8.5*100 T'bird VIA VT8363 (no "A") Northbridge & VT82C686A (Southbridge). KT133 no A. No HPT366. I had terrible read errors on a single UDMA66 HD: one in 5 md5sums on an unmounted 1.5 GB partition was different. WD Diags said drives were good (sectors verified OK). Swapped PS, RAM, HDs, cables, PCI cards, 2.2/2.4/FreeBSD kernels, nothing helped ... ... until I slowed the SDRAM down from the PC133 (it really _is_ and passes memtest-86 and my burnMMX) down to PC100. At least UDMA is still working, even if my RAM is decidedly slower. YMMV I've now tested 9 hrs copying a 500 MB file back and forth on the same drive without error. 21 hrs copying back and forth and md5sum'ing from /dev/hdc3 [UDMA66] is OK too. -- Robert author `cpuburn` http://users.ev1.net/~redelm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Test
Test - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5 -ac series broken on Sparc64
i've successfully built the 2.4.5 vanilla kernel. I went to check the -ac series, and each [1-4] breaks in the same way on Sparc64 platform: include/linux/irq.h:61: asm/hw_irq.h: No such file or directory *** [sched.o] Error 1 a find . -name 'hw_irq.h' shows appropriate versions in i386, ia64, mips, mips64, alpha, ppc, parisc, um, and sh Is this is a ports-maintainer issue, or what? Surely breaking the sparc platform is not in the future plans... Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 kernel freeze
Stephan Brauss <[EMAIL PROTECTED]> writes: > > Any other hints are welcome (other than the noapic, which didn't help). > My system is always completely dead as soon as I start a larger (interrupt > driven?) data transfer to/from any (? I tested with two different NICs and a Promise > Ultra100) PCI card in slot 4 or 5. And it seems that it really only occurs > in slots 4 and 5... To get rid of it, I switched to 2.2.19. I couldn't. Problems getting devfsd patched in 2.2.19 :-( - and I'm going on vacation in shortly... Now after the last couple of "lost interrupts" I set a debian-stable as my primary firewall/router box in front of my server - this way I got rid of the second nic and freed both slot 4 and 5. Unfortunately, after a couple hours running my box again lost irq :-(. And there's no obvious huge transfer going on. The boxes were just alone. Now I try again noapic (different setup). Hope that works. Otherwise I'm kind of lost... -- Tschoe,Get my gpg-public-key here Jens http://gecius.de/gpg-key.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] sched_yield in 2.2.x
Hello,
I'm not subscribed, so eventual replies please CC: to me ([EMAIL PROTECTED]).
Here is a 2-line patch that fixes sched_yield() call to actually really yield
the processor in 2.2.x kernels. I am using 2.2.16 and so have tested it in
2.2.16 only, but I suppose it should work with other kernels as well (there
seem not to be so many changes).
Bug description: When a process called sched_yield() it was properly marked for
reschedule and bit SCHED_YIELD for reschedule was properly set in p->policy.
However, prev_goodness() cleared this bit returning goodness 0 (I changed it to
-1 just to be sure this process isn't accidentally picked when there is other
process to run - maybe I'm wrong here, but 2.4.5 gives it also goodness -1, so
it should be OK). This was not that bad, but successive calls to goodness()
while searching for next process to run included last process, which had
meanwhile YIELD bit cleared and thus it's goodness value was calculated as
better. And we come to second line of the fix - do not consider prev process in
searching for next process to run, as it is anyway already selected as next by
default when no better process is found.
I hope that it will work in SMP environment as well (it should, since
schedule() seems to be mostly independent of UP/SMP).
And why do I want to use sched_yield()? Well, to implement user-space
longer-duration locks which don't consume the whole timeslice when waiting, but
rather relinquish processor to other task so it finishes it's work in critical
region sooner.
It's funny nobody has fixed this by now, but as I've seen there were couple
of discussion about sched_yield() already... I come probably too late...
Ivan Schreter
[EMAIL PROTECTED]
--- kernel/sched.c.orig Wed May 30 01:17:24 2001
+++ kernel/sched.c Wed May 30 01:41:34 2001
@@ -196,7 +196,7 @@
{
if (p->policy & SCHED_YIELD) {
p->policy &= ~SCHED_YIELD;
- return 0;
+ return -1;
}
return goodness(prev, p, this_cpu);
}
@@ -729,7 +729,7 @@
* list, so our list starting at "p" is essentially fixed.
*/
while (p != _task) {
- if (can_schedule(p)) {
+ if (p != prev && can_schedule(p)) {
int weight = goodness(prev, p, this_cpu);
if (weight > c)
c = weight, next = p;
Re: Linux 2.4.5-ac2
yes I get a performance improvement of about 5% could you port your patches to the 2.4.5-ac4 kernel? I'd love to see if the ac improvements and yours add to each other. Thanks, - Fabio Jens Axboe wrote: > On Tue, May 29 2001, Fabio Riccardi wrote: > > "Leeuw van der, Tim" wrote: > > > > > But the claim was that 2.4.5-ac2 is faster than 2.4.5 plain, so which > > > changes are in 2.4.5-ac2 that would make it faster than 2.4.5 plain? Also, I > > > don't know if 2.4.5-ac1 is as fast as 2.4.5-ac2 for Fabio. If not, then it's > > > a change in the 2.4.5-ac2 changelog. If it is as fast, it is one of the > > > changes in the 2.4.5-ac1 changelog. > > > > 2.4.5-ac1 crashed on my machine, vanilla 2.4.5 worked but slower than 2.4.2 > > > > 2.4.5-ac2 is _a lot_ faster than all the 2.4.4 and of vanilla 2.4.5 > > > > please notice that I have a 4G machine, dual proc, and I run a very > > memory/IO/CPU intensive test, so your mileage may vary with different > > applications. > > Could you try the 4GB I/O patches and see if they boost performance of > such cases? > > *.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.5/ > > -- > Jens Axboe > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 84 bugs in 2.4.4/2.4.4-ac8 where NULL pointers are deref'd
> And if you look a couple lines previous it is blindly dereferenced,
> this should have been a clue :-)
There's a lot of places where code checks and then blindly
dereferences, so I don't think that's much of a clue ;-)
> > Start --->
> >struct rtable *rt = skb ? (struct rtable*)skb->dst : NULL;
> >
> >if (!opt) {
> >opt = &(IPCB(skb)->opt);
> >memset(opt, 0, sizeof(struct ip_options));
> > Error --->
> >iph = skb->nh.raw;
> How is this a contradiction? The first thing sets 'rt' to NULL or
In the absence of knowlege about variable dependencies (in this case
that skb == NULL implies opt != NULL) the code appears contradictory,
since it checks skb against null and then dereferences it downstream.
We'd make the checker read comments to infer such knowlege if there
were more of them ;-)
> > Start --->
> >if (skb->dst == NULL) {
> >if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
> >goto drop;
> >}
> >
> > #ifdef CONFIG_NET_CLS_ROUTE
> > Error --->
> >if (skb->dst->tclassid) {
>
> This one is OK.
>
> The side effect of a successful ip_route_input call is that skb->dst
> gets set to a non-NULL value.
Argh. I was missing the fact that skb was getting passed to a function.
Sorry about the false pos.
> > Start --->
> >if (ifa == NULL && cmd != SIOCSIFADDR) {
> >ret = -EADDRNOTAVAIL;
> >goto done;
> >}
> >
> >switch(cmd) {
> >case SIOCGIFADDR:
> > Error --->
> >*((dn_address *)sdn->sdn_nodeaddr) = ifa->ifa_local;
> >goto rarok;
> >
> >case SIOCSIFADDR:
>
> Checker is wrong in these two cases.
>
> The "error" code you point to cannot be reached if cmd == SIOCGIFADDR
> (for the dn_dev.c, likewise SIOCSIFADDR+SIOCSIFFLAGS in the devinet.c
> case). In the dn_dev.c case, SIOCSIFADDR in that switch statement may
> run if ifa == NULL.
Yeah, it's not doing sophisticated false path pruning (yet). I thought
I would have caught this.
> isn't doing exhaustive enough reachability determination.
Too exhaustive, since it follows impossible paths.
Thanks for the quick feedback! And apologies for the bogus "errors".
Dawson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 4 security holes in 2.4.4-ac8
> > [BUG] raddr seems to be a user pointer, but is written at the end of
> > the system call.
> >
> > ipc/shm.c: ERROR: system call 'sys_shmat' derefs non-tainted param= 3
> >
> > asmlinkage long sys_shmat (int shmid, char *shmaddr, int shmflg, ulong *raddr)
> > {
> > struct shmid_kernel *shp;
> >
> >
> >...
> > *raddr = (unsigned long) user_addr;
> > err = 0;
> > if (IS_ERR(user_addr))
> > err = PTR_ERR(user_addr);
> > return err;
>
> Believe it or not, this one is OK :-)
>
> All callers pass in a pointer to a local stack kernel variable
> in raddr.
Ah. I assumed that "sys_*" meant that all pointers were from user space ---
is this generally not the case? (Also, are there other functions called
directly from user space that don't have the sys_* prefix?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 84 bugs in 2.4.4/2.4.4-ac8 where NULL pointers are deref'd
[ Steve: Just skim down to the decnet bug, you should have a look
at it.
Philip: Similarly, skim down to the econet bug. ]
Dawson Engler writes:
> [BUG] sends sk raw to a bunch of other routines. doesn't seem good.
> /u2/engler/mc/oses/linux/2.4.4-ac8/net/ipv4/ip_output.c:520:ip_build_xmit_slow:
>ERROR:INTERNAL_NULL:502:520: [type=set] (set at line 502) Dereferencing NULL ptr "sk"
>illegally!
>
> /*
> * Begin outputting the bytes.
> */
>
> Start --->
> id = (sk ? sk->protinfo.af_inet.id++ : 0);
>
> ... DELETED 12 lines ...
>
>
> /*
> * Fill in the control structures
> */
>
> Error --->
> skb->priority = sk->priority;
> skb->dst = dst_clone(>u.dst);
> skb_reserve(skb, hh_len);
Actually, sk is not allowed to be NULL here, the "(sk ?" bit is bogus
and was cut and pasted from elsewhere. I've removed it in my tree.
And if you look a couple lines previous it is blindly dereferenced,
this should have been a clue :-)
> -
> [BUG] hard to follow but seems like it.
> /u2/engler/mc/oses/linux/2.4.4-ac8/net/ipv4/fib_frontend.c:272:fib_validate_source:
>ERROR:INTERNAL_NULL:239:272: [type=set] (set at line 239) Dereferencing NULL ptr
>"itag" illegally!
> if (fib_lookup(, ))
> goto last_resort;
> if (res.type != RTN_UNICAST)
> goto e_inval_res;
> *spec_dst = FIB_RES_PREFSRC(res);
> Start --->
> if (itag)
>
> ... DELETED 27 lines ...
>
>
> last_resort:
> if (rpf)
> goto e_inval;
> *spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
> Error --->
> *itag = 0;
> return 0;
Another case like the previous, no caller sends in a NULL itag.
Check removed in my sources...
> [BUG] contradiction
> /u2/engler/mc/oses/linux/2.4.4/net/ipv4/ip_options.c:257:ip_options_compile:
>ERROR:INTERNAL_NULL:252:257: [type=set] (set at line 252) Dereferencing NULL ptr
>"skb" illegally! [val=500]
> int l;
> unsigned char * iph;
> unsigned char * optptr;
> int optlen;
> unsigned char * pp_ptr = NULL;
> Start --->
> struct rtable *rt = skb ? (struct rtable*)skb->dst : NULL;
>
> if (!opt) {
> opt = &(IPCB(skb)->opt);
> memset(opt, 0, sizeof(struct ip_options));
> Error --->
> iph = skb->nh.raw;
> opt->optlen = ((struct iphdr *)iph)->ihl*4 - sizeof(struct iphdr);
> optptr = iph + sizeof(struct iphdr);
> opt->is_data = 0;
How is this a contradiction? The first thing sets 'rt' to NULL or
not, then we test '!opt' not '!rt' which is what I think you are
seeing :-)
If SKB is NULL, opt must be non-NULL and also opt->is_data must be
set in this case. That is the invariant, and even though not %100
explicitly tested, this is what the comment above is trying to say.
At best the missing minor checks should be BUG() checks because they
are illegal states.
> [BUG] contradiction
> /u2/engler/mc/oses/linux/2.4.4/net/core/neighbour.c:317:neigh_create:
>ERROR:INTERNAL_NULL:312:317: [type=set] (set at line 312) Dereferencing NULL ptr
>"parms" illegally! [val=500]
> return ERR_PTR(error);
> }
>
> /* Device specific setup. */
> if (n->parms && n->parms->neigh_setup &&
> Start --->
> (error = n->parms->neigh_setup(n)) < 0) {
> neigh_release(n);
> return ERR_PTR(error);
> }
>
> Error --->
> n->confirmed = jiffies - (n->parms->base_reachable_time<<1);
>
> hash_val = tbl->hash(pkey, dev);
I've added the obvious check, but I suspect the more correct fix is
to disallow NULL n->parms (and as a consequence disallow NULL
tbl->constructor since that constructor is the thing that hooks
in the n->parms).
Really, I didn't catch anyone sending a NULL parms in during a
quick perusal, and honestly it would crash instantly on non-x86
systems if it were NULL. (Unfortunately, at least during boot,
the NULL address is actually mapped in the kernel on x86 :-( ).
> -
> [BUG] contradicts
> /u2/engler/mc/oses/linux/2.4.4/net/ipv4/ip_input.c:325:ip_rcv_finish:
>ERROR:INTERNAL_NULL:319:325: [type=set] (set at line 319) Dereferencing NULL ptr
>"dst" illegally! [val=600]
>
> /*
> * Initialise the virtual path cache for the packet. It describes
> * how the packet travels inside Linux networking.
> */
> Start --->
> if (skb->dst == NULL) {
> if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
> goto drop;
> }
>
> #ifdef CONFIG_NET_CLS_ROUTE
> Error --->
> if (skb->dst->tclassid) {
> struct ip_rt_acct *st = ip_rt_acct +
RE: [PATCH] fix more typos in Configure.help and fs/nls/Config.in
> > Official country name: Belarus > > Language/Nationality: Belarusian > > > > Standard has taken things right as we pronounce them. > > > > Please apply the patch. > > Done. Thanks for confirming it is correct You forgot to apply the second part: --- Config.in.orig Wed May 30 00:27:45 2001 +++ Config.in Mon May 28 19:32:25 2001 @@ -29,7 +29,7 @@ tristate 'Codepage 852 (Central/Eastern Europe)' CONFIG_NLS_CODEPAGE_852 tristate 'Codepage 855 (Cyrillic)' CONFIG_NLS_CODEPAGE_855 tristate 'Codepage 857 (Turkish)'CONFIG_NLS_CODEPAGE_857 - tristate 'Codepage 860 (Portugese)' CONFIG_NLS_CODEPAGE_860 + tristate 'Codepage 860 (Portuguese)' CONFIG_NLS_CODEPAGE_860 tristate 'Codepage 861 (Icelandic)' CONFIG_NLS_CODEPAGE_861 tristate 'Codepage 862 (Hebrew)' CONFIG_NLS_CODEPAGE_862 tristate 'Codepage 863 (Canadian French)'CONFIG_NLS_CODEPAGE_863 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent "#ifdef __KERNEL__" on different architectures
On Sun, May 27, 2001 at 11:10:00PM +0100, Philip Blundell wrote: > >--- include/asm-arm/atomic.h.old Sun May 27 22:30:58 2001 > >+++ include/asm-arm/atomic.h Sun May 27 22:58:20 2001 > >@@ -12,6 +12,7 @@ > > * 13-04-1997 RMK Made functions atomic! > > * 07-12-1997 RMK Upgraded for v2.1. > > * 26-08-1998 PJB Added #ifdef __KERNEL__ > >+ * 27-05-2001 APB Removed #ifdef __KERNEL__ > > */ > > #ifndef __ASM_ARM_ATOMIC_H > > #define __ASM_ARM_ATOMIC_H > >@@ -30,7 +31,6 @@ > > This is no good. The ARM kernel just doesn't provide any atomic primitives > that will work in user space. If you want atomicity you have to use > libpthread. Similar on some MIPS processors where the kernel has to implement atomic operations because there is no practical possibility to implement them in userspace. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: new aic7xxx oopses with AHA2940
* Justin T. Gibbs schrieb am 29.05.01 um 20:55 Uhr: > >OK. Now I cut out the Oops out of my /var/log/messages, then did > > Can you provide the full dmesg from a working kernel for you system? > I need to know the type of controller in use as well as some other > system attributes. > sure. but its only the old aic7xxx driver. The new one is not working . I was one thing missing, sorry: The new driver has been working. He did it since I installed Wi* 2k on the 4G scsi-disk (maybe random?). Maybe that fuc Billysoft has "tuned" my Controller firmware?? I don't think (hope!) thats possible... dmesg: Linux version 2.4.5 (root@homer) (gcc version 2.95.2 19991024 (release)) #5 Sun May 27 13:11:31 CEST 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ffec000 (usable) BIOS-e820: 1ffec000 - 1ffef000 (ACPI data) BIOS-e820: 1ffef000 - 1000 (reserved) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: - 0001 (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009fc00 for 4096 bytes. On node 0 totalpages: 131052 zone(0): 4096 pages. zone(1): 126956 pages. zone(2): 0 pages. mapped APIC to e000 (01884000) Kernel command line: auto BOOT_IMAGE=linux ro root=307 Initializing CPU#0 Detected 807.220 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1608.90 BogoMIPS Memory: 512868k/524208k available (1333k kernel code, 10952k reserved, 471k data, 184k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xf1150, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 Found VT82C686A, not applying VIA latency patch. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 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 pty: 256 Unix98 ptys configured Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10d block: queued sectors max/low 340869kB/209797kB, 1024 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 21 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:04.1 ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio PDC20265: IDE controller on PCI bus 00 dev 88 PCI: Found IRQ 10 for device 00:11.0 PCI: The same IRQ used for device 00:0b.0 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later ide2: BM-DMA at 0x7800-0x7807, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0x7808-0x780f, BIOS settings: hdg:pio, hdh:pio hda: ST320430A, ATA DISK drive hdc: Pioneer DVD-ROM ATAPIModel DVD-105S 011, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 40079088 sectors (20520 MB) w/512KiB Cache, CHS=39761/16/63, UDMA(66) Partition check: hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 > SCSI subsystem driver Revision: 1.00 PCI: Found IRQ 9 for device 00:0d.0 PCI: The same IRQ used for device 00:04.2 PCI: The same IRQ used for device 00:04.3 (scsi0) found at PCI 0/13/0 (scsi0) Narrow Channel, SCSI ID=7, 16/255 SCBs
empeg-car serial-over-USB driver
Has anybody used this successfully in a recent kernel? With 2.4.5 it seems to detect the device successfully: empeg.c: v1.0.0 Greg Kroah-Hartman <[EMAIL PROTECTED]>, Gary Brubaker <[EMAIL PROTECTED]> empeg.c: USB Empeg Mark I/II Driver usbserial.c: Empeg converter detected usbserial.c: Empeg converter now attached to ttyUSB0 (or usb/tts/0 for devfs) but the machine locks up when I try to talk to it. This is on i386 using the usb-uhci driver. p. PGP signature
[CHECKER] 4 security holes in 2.4.4-ac8
Hi All,
Enclosed are four bugs where 2.4.4-ac8 kernel code appears to directly
read/write user space pointers. The latter three were found after
forming equivalence classes by:
(1) recording all routines assigned to the same function pointer
field in a structure
(2) if any member of the equiv class treated a parameter as a
user-space pointer, checking that they all do.
Let me know if any of these are wrong. The first one seems pretty bad.
Dawson
---
[BUG] raddr seems to be a user pointer, but is written at the end of
the system call.
ipc/shm.c: ERROR: system call 'sys_shmat' derefs non-tainted param= 3
asmlinkage long sys_shmat (int shmid, char *shmaddr, int shmflg, ulong *raddr)
{
struct shmid_kernel *shp;
...
*raddr = (unsigned long) user_addr;
err = 0;
if (IS_ERR(user_addr))
err = PTR_ERR(user_addr);
return err;
-
[BUG] ./drivers/usb/bluetooth.c: dereference of 'buf' at the beginning of
the switch, and then does a copyin.
ERROR: equivalence class contains
2 functions that taint parameter <2>, and 1
functions that dereference it raw.
Tainting functions
[ acm_tty_write:acm.c ]
[ serial_write:usbserial.c ]
Dereferencing functions
[ bluetooth_write:bluetooth.c ]
switch (*buf) {
/* First byte indicates the type of packet */
case CMD_PKT:
/* dbg(__FUNCTION__ "- Send cmd_pkt len:%d", count);*/
if (in_interrupt()){
printk("cmd_pkt from interrupt!\n");
return count;
}
new_buffer = kmalloc (count-1, GFP_KERNEL);
if (!new_buffer) {
err (__FUNCTION__ "- out of memory.");
return -ENOMEM;
}
if (from_user)
copy_from_user (new_buffer, buf+1, count-1);
else
memcpy (new_buffer, buf+1, count-1);
---
In the equivalence class for file_operations:write: 55 functions treat
their second parameter as tainted, but two functions use it raw.
[BUG]
/* drivers/char/sbc60xxwdt.c: buf is tainted */
static ssize_t fop_write(struct file * file, const char * buf, size_t count, loff_t *
ppos)
{
/* We can't seek */
if(ppos != >f_pos)
return -ESPIPE;
/* See if we got the magic character */
if(count)
{
size_t ofs;
/* note: just in case someone wrote the magic character
* five months ago... */
wdt_expect_close = 0;
/* now scan */
for(ofs = 0; ofs != count; ofs++)
if(buf[ofs] == 'V')
wdt_expect_close = 1;
/* Well, anyhow someone wrote to us, we should return that favour */
next_heartbeat = jiffies + WDT_HEARTBEAT;
}
return 0;
}
[BUG]
/* drivers/usb/mdc800.c: buf is tainted */
static ssize_t mdc800_device_write (struct file *file, const char *buf, size_t len,
loff_t *pos)
{
int i=0;
spin_lock (>io_lock);
if (mdc800->state != READY)
{
spin_unlock (>io_lock);
return -EBUSY;
}
if (!mdc800->open )
{
spin_unlock (>io_lock);
return -EBUSY;
}
while (iio_lock);
return -EINTR;
}
/* check for command start */
if (buf [i] == (char) 0x55)
{
mdc800->in_count=0;
Here's the equiv classes:
Tainting functions
[ ac_write:applicom.c ]
[ affs_file_write:file.c ]
[ block_write:ksyms.c ]
[ camera_write:dc2xx.c ]
[ cap_info_write:file_cap.c ]
[ capi_write:capi.c ]
[ capinc_raw_write:capi.c ]
[ coda_file_write:file.c ]
[ coda_psdev_write:psdev.c ]
[ cs4281_midi_write:cs4281m.c ]
[ cs4281_write:cs4281m.c ]
[ dev_irnet_write:irnet_ppp.h ]
[ dev_write:raw1394.c ]
[ ds_write:ds.c ]
[ dtlk_write:dtlk.c ]
[ emu10k1_audio_write:audio.c ]
Re: Swap problems persisting?
> I found myself in trouble with sudden shutdowns while playing DVDs (LiViD) and >sometimes > running Mozilla 0.8.1 simultaneously, but running mozilla wasn't always necessary. > Describe "sudden shutdown" more precisely first of all - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] 84 bugs in 2.4.4/2.4.4-ac8 where NULL pointers are deref'd
Hi All,
enclosed are 84 potential errors where code
(1) checks if a pointer is null
(2) dereferences it anyway.
For example the code:
Start --> if (!(result = iget(dir->i_sb, ino))) {
hpfs_unlock_iget(dir->i_sb);
Error ---> hpfs_error(result->i_sb,"hpfs_lookup: can't get inode");
Checks that "result" is null, and then dereferences it to emit an error message.
In most cases either (1) the check is unnecessary (the pointer cannot
be null) or (2) there is a real error. The errors are typically fairly
clear, though I'm sure there's still some false positives of errors
prevented because of data dependencies.
The sort-of breakdown is:
2.4.4-specific errors = 1
2.4.4ac8-specific errors= 36
Common errors = 47
Total = 84
This is a little bogus since I think all the ac8 errors are also in
2.4.4 --- I used a worse checker on 2.4.4 and haven't rerun the results.
One of the most amusing patterns was a profligate cut of the
following loop:
Start ---> while (*handleptr && (*handleptr != handle))
handleptr = &((*handleptr)->dnext);
Error ---> *handleptr = (*handleptr)->dnext;
Where either the check of *handleptr is redundant, or the raw dereference
after the loop is wrong.
The loop appeared in a lot of different places, though the variables
were renamed:
Start ---> while (*listptr && (*listptr != list))
listptr = &((*listptr)->next);
Error ---> *listptr = (*listptr)->next;
Start ---> while (*devptr && (*devptr != dev))
devptr = &((*devptr)->next);
Error ---> *devptr = (*devptr)->next;
Anyway, if you notice any broken output, please let me know.
Dawson
-
# BUGs | File Name
5 | fs/hpfs/super.c
4 | drivers/input/input.c
3 | drivers/net/aironet4500_core.c
3 | drivers/atm/iphase.c
2 | drivers/char/epca.c
2 | fs/ext2/dir.c
2 | drivers/scsi/in2000.c
2 | drivers/char/joystick/serio.c
2 | fs/ufs/dir.c
2 | fs/ufs/super.c
2 | drivers/net/hamradio/soundmodem/sm.c
2 | drivers/video/matrox/matroxfb_base.c
2 | drivers/char/joystick/gameport.c
2 | drivers/net/wan/comx.c
1 | drivers/net/wan/sdla_chdlc.c
1 | net/decnet/dn_route.c
1 | net/ipv4/ip_input.c
1 | drivers/char/ip2main.c
1 | drivers/ide/pdc202xx.c
1 | drivers/ide/aec62xx.c
1 | drivers/media/video/bttv-driver.c
1 | net/irda/irqueue.c
1 | drivers/ide/hpt34x.c
1 | drivers/ide/hpt366.c
1 | drivers/input/evdev.c
1 | drivers/isdn/hysdn/hysdn_net.c
1 | drivers/ide/alim15x3.c
1 | drivers/ide/sis5513.c
1 | drivers/scsi/aha152x.c
1 | net/ipv4/devinet.c
1 | drivers/block/nbd.c
1 | drivers/ide/cmd64x.c
1 | net/ipv4/ip_output.c
1 | drivers/md/lvm-snap.c
1 | net/ipv4/ip_options.c
1 | drivers/ide/amd7409.c
1 | drivers/char/stallion.c
1 | drivers/net/cs89x0.c
1 | net/ipv4/fib_frontend.c
1 | drivers/net/wan/sdlamain.c
1 | fs/nfs/dir.c
1 | net/econet/af_econet.c
1 | drivers/input/joydev.c
1 | drivers/ide/osb4.c
1 | drivers/message/fusion/mptscsih.c
1 | drivers/net/wan/comx-hw-comx.c
1 | drivers/scsi/AM53C974.c
1 | drivers/net/pcmcia/xirc2ps_cs.c
1 | drivers/video/fbcon-mfb.c
1 | drivers/acpi/interpreter/amresolv.c
1 | drivers/input/mousedev.c
1 | fs/ntfs/inode.c
1 | drivers/scsi/pcmcia/../aha152x.c
1 | drivers/scsi/g_NCR5380.c
1 | drivers/net/pcmcia/xircom_cb.c
1 | drivers/scsi/megaraid.c
1 | drivers/scsi/aic7xxx/aic7xxx_linux.c
1 | net/core/neighbour.c
1 | drivers/video/fbcon-hga.c
1 | fs/hpfs/dir.c
1 | drivers/scsi/aic7xxx/aic7xxx.c
1 | net/decnet/dn_dev.c
1 | drivers/ide/piix.c
# 2.4.4 specific errors
#
-
[BUG] [GEM]
/u2/engler/mc/oses/linux/2.4.4/drivers/acpi/interpreter/amresolv.c:72:acpi_aml_get_field_unit_value:
ERROR:INTERNAL_NULL:68:72: [type=set] (set at line 68) Dereferencing NULL ptr
"field_desc" illegally! [val=400]
u32 mask;
u8 *location = NULL;
u8 locked = FALSE;
Start --->
if
Swap problems persisting?
I read in KT that virtual memory is a problem in recent 2.4 kernels. I found myself in trouble with sudden shutdowns while playing DVDs (LiViD) and sometimes running Mozilla 0.8.1 simultaneously, but running mozilla wasn't always necessary. That was with all 2.4.5 and following ac kernels. I had performance troubles with 2.4.4 so I couldn't really push those, ie. the problems could be there as I well. It seems though (from my perspective) that cutting out shmem and DRI stabilizes it a whole lot. Right now I'm running 2.4.5-ac4 and have after a few hours not been able to crash it. I made it without DRI and support for shmem fs. Are there still known problems with those, ie. /dev/shmem and DRI? I have an ATI Rage Fury 128 with XFree86 4.0.2 in case it matters. Please cc: me in case you reply, as I'm not on the list. Thanks, Peter P.S. I always go back to 2.4.1 that was rock solid and the fastest kernel yet for my system :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROMISE+ATHLON crashes with 2.4.3ac7 or higher. workaround?
Hi all, I faced several system hangs with an ASUS A7V133 using a kernel 2.4.3ac7 or higher. (I reported this some time ago) Now I removed the 2 hard drives from the promise controller and attached them an to the via controller. After that step I could not reproduced the system freeze at least with 2.4.5. So I __guess__ that the promise controller in combination with the VIA PCI Interface leads to some trouble. I will do some further investigations, to find out, if the promise controller was my problem. Just ask if you need more information. greetings Christian Bornträger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
{OT?]Re: VIA KT133A Northbridge bug reported
On Tue, 29 May 2001, Joseph Carter wrote: > On Tue, May 29, 2001 at 03:56:15PM +0200, Holger Lubitz wrote: > > Translation: "As Stephan Schwolow from MSI Germany told Chip Online, the > > problem with the VIA northbridge can be identified by a warm start from > > DOS or a Windows reboot: If the screen stays black, the chip has an > > error." > > > > As far as I understand it, the problem is only affecting "warm reboots". > > And I couldn't care less about warm reboots - my machines usually run > > 24/7 :) > > I have seen this problem sometimes. I don't read German though - does the > page mention a fix? > In:- http://www.theinquirer.net/28050107.htm it claims that MSI are offering swaps of their KT7 MBs of those steppings with MBs with the latest stepping. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] panic in scsi_free/sr_scatter_pad
Jens Axboe wrote: > > On Tue, May 29 2001, Paul Gortmaker wrote: > > I think I recall seeing something reported like this on the list(?): > > > > sr: ran out of mem for scatter pad > > Kernel panic: scsi_free: bad offset > > Here's a better patch, it also gets the freeing right. It's been fixed > for long, just haven't been sent to Linus yet. It's in Alan's tree, and > in fact I think I've send it to this list more than once :) Ok, essentially same patch - good to see. Seems old rule of thumb[1] for linux patches still applies :) I see you opted for a new var. to store old use_sg value, rather than make use of SCpnt->old_use_sg like I did. Was curious as to your reasoning for that - maybe I'm overlooking something. Other thing that crossed my mind was the appropriateness of scsi_free() doing a panic. For this particular case, a BUG() would have been more informative if we were relying on info in a bug report from Joe Average to solve the problem. (Also, panic is a bit harsh if say CD is only SCSI device and everything else is EIDE, but scsi_free has no way of knowing...) Paul. [1] Odds are somebody has already posted the patch you just finished... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Status of ALi MAGiK 1 support in 2.4.?
Alan Cox wrote: > > May 22 21:45:07 pollux kernel: ALI15X3: simplex device: DMA disabled > > May 22 21:45:07 pollux kernel: ide0: ALI15X3 Bus-Master DMA disabled > > (BIOS) > > May 22 21:45:07 pollux kernel: ALI15X3: simplex device: DMA disabled > > May 22 21:45:07 pollux kernel: ide1: ALI15X3 Bus-Master DMA disabled > > The DMA was off because the BIOS left it off. I just checked, and the BIOS auto-detect page for that drive shows PIO Mode 4 and Ultra DMA Mode 5. The BIOS also shows a summary chart during boot, just before the LILO prompt, and that summary also reports UDMA 5 for that drive. It really looks like the kernel is not getting the correct device info from the BIOS. As I mentioned earlier, the A7A266 supposedly has an ALi M1535D+ southbridge "with PCI Super-I/O Integrated Peripheral Controller (PSIPC)", rather than the ALI15X3 reported by the kernel. Thanks, Bobby Bryant Austin, Texas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems under 2.4.4/5
In article <[EMAIL PROTECTED]>, Narayan Desai <[EMAIL PROTECTED]> wrote: >> "Mike" == Miquel van Smoorenburg <[EMAIL PROTECTED]> writes: > >Mike> In article <[EMAIL PROTECTED]>, >Mike> Narayan Desai <[EMAIL PROTECTED]> wrote: >>> Hi. I have started having serial console problems in the last bunch >>> of kernel releases. I have tried various 2.4.4 and 2.4.5 ac kernels >>> (up to and including 2.4.5-ac4) and the problem has persisted. The >>> problem is basically that serial console doesn't recieve. > >Mike> The serial driver now pays attention to the CREAD bit. Sysvinit >Mike> clears it, so that's where it goes wrong. > >Mike> I don't think this change should have gone into a 'stable' >Mike> kernel version. 2.5.0 would have been fine, not 2.4.4 Okay it was 2.4.3 when it went in >How would I go about resetting this so that serial console worked >again? thanks... Fix sysvinit. Oh and all getty programs etc - everything that mucks around with termios. Alternatively revert the change to drivers/char/serial.c See also http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg42426.html Oh *ahem* I just read the entire thread again and I remembered it wrong. It's not the CREAD handling perse, it's something else that has changed that caused this, but it appears that a solution hasn't been found yet. Except for fixing all user-space programs. Sysvinit, agetty, busybox etc etc Okay so ignore my earlier comments. Sorry. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Promise Ultra 100 TX2
> I just bought one of $subject (PDC 20268) > > Removed a Ultra 66 from my system and plugged the new one into the 66Mhz > PCI-Bus (Intependent from the 33Mhz PCI-Bus (Tyan Thunder HE-SL Mainboard > with Serverworks HE-SL-Chipset)) > > Kernel is 2.4.4 with Promise support compiled in. (The Ultra 66 works like > a charm with this kernel) > > > But the new controller wasn't deteced by the IDE-Subsystem AT ALL. (It > only showed the onboard OSB4-Adapter) with "ide.2.4.4-p1.04092001.patch.bz2" it now works like a charm. :-) (As there is no update in 2.4.5 or in (current) 2.4.5ac4 i look what Andre has produced and found that patch.) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
On Tue, 29 May 2001, Alan Cox wrote: > > In BSD, select() states that when a time out occurs, the bits passed to > > select will not be altered. In Linux, which claims BSD compliancy for this > > Nope. BSD manual pages (the authentic ones anyway) say that the timeout value > may well be written back but that this was a future enhancement and that users > shoulsnt rely on the value being unchanged. The reference was to the fdsets passed in if I read the original post correctly. William Astle finger [EMAIL PROTECTED] for further information Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ handling in SMP environment, kernel 2.4.3
On Tue, 29 May 2001, Hilik Stein wrote: > I am running a Linux machine with a 1GB Ethernet card which takes a > huge amount of packets, which results in many HW interrupts. is it > possible to make sure that only CPU #1 handles all the hardware > interrupts generated by the NIC ? or even all the hardware interrupts > in the systems if its too much to ask to filter IRQ based on origin ? > thanks Hilik Stein yes this is possible with the 2.4 kernels. Check out Documentation/IRQ-affinity.txt. You can bind hardware interrupts to any CPU (or arbitrary group of CPUs). Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
> a reasonably stable release until 2.2.12. I do not understand why > code with such serious reproducible problems is being introduced into > the even numbered kernels. What happened to the plan to use only the Who said it was introduced ?? It was more 'lurking' than introduced. And unfortunately nobody really pinned it down in 2.4test. > By the way, The 2.4.5-ac3 kernel still fills swap and runs out of > memory during my morning NFS incremental backup. I got this message > in the syslog. 2.4.5-ac doesn't do some of the write throttling. Thats one thing I'm still working out. Linus 2.4.5 does write throttling but Im not convinced its done the right way > completely full. By that time the memory was in a reasonable state > but the swap space is still never being released. It wont be, its copied of memory already in apps. Linus said 2.4.0 would need more swap than ram when he put out 2.4.0. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: console colors messed up with 2.4.X Rivafb driver
On Tue, May 29, 2001 at 05:03:54PM +0200, Bakonyi Ferenc wrote: > > Hi! > > Steven A. DuChene wrote: > > I have a Riva128 based video card in a older SMP P-Pro system and with all > > of the lastest 2.4 series of kernels (mostly the ac stuff) I have screwy colors > > on the console (the penguin boot logos are shades of blue) and initially when > > I start X (XFree86 4.0.3) the colors are very dark until I switch to a console > > and back again. Once I switch to a console and back to X things are fine in > Pressing 'ctrl alt +' and 'ctrl alt -' is enough. On Riva 128 cards > rivafb uses 8 bit color registers but XFree86 4.0.x still uses 6 bit > color registers. > > >... > > The fbset output on this system says: > > > > mode "1280x1024-74" > > # D: 135.007 MHz, H: 78.859 kHz, V: 74.116 Hz > > geometry 1280 1024 1280 1024 16 > > timings 7407 256 32 34 3 144 3 > > accel true > > rgba 5/11,6/5,5/0,0/0 > ^^^ > This line indicates you are using rivafb in 16 bpp mode. Unfortunetly > 16 bpp is not supported by Riva 128 hw. It's a bug, in a perfect > world rivafb should disable 16 bpp mode on Riva 128. In this case > hardware is set to 15 bpp, but rivafb thinks it's set to 16 bpp. (Or > something similar.) > > Fastest solution: try using 15 bpp or 32 bpp. Well, since the video card only has 4Mb of memory I tried 15 bpp but then I kept getting a kernel Opps from a function in the rivafb driver. I will try to catch it to see an exact error but it is difficult as the Opps eventually halts the system and the error is not capturable. > > > endmode > > > > The same thing still occurs if I set the color depth to 8 bit. > If you boot with 8 bpp and you do not use X, console and logo colors > should be fine. Please detail this problem! I did boot with 8 bpp and it does indeed seem to be fine. Got two correctly colored penguin logos and system did not Opps. BTW, when the system Opps with 15 bpp I don't see the penguin logos at all. There is blank space at the top of the screen during booting where they would normally be displayed but they aren't there. With the screwed up colors (but no-Opps'ing system) at 16 bpp I do see the two penguin logos but as I said they are various shades of blue only. > > > > > This is a pci card with 4Mb of video memory. I also have a AMD K6 system with a >16Mb > > AGP TNT2 card and this does not happen on that machine. > > > > BTW, why is the mtrr for the Riva set to 0M ??? > Because you said yes to 'Processor type and features ---> MTRR > (Memory Type Range Register) support'. > Shouldn't that indicate that the system should allocate & use mtrr registers & memory? It does on other systems I have. -- Steven A. DuChene [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.mindspring.com/~sduchene/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Transparent proxy support in linux 2.4 ?
How can I simulate the linux 2.2.x transparent proxy support in linux 2.4? Using linux 2.2 on my router I can bind() a socket to an address X and then connect() to another host Y. Y would see an incoming connection from X and reply accordingly: if the replies towards X pass through my router they are rerouted towards the local socket and all works smoothly. This is a (IMO) tricky hack to fake requests from host X: it is used for example by nat-enabled IDENT servers that forward the incoming requests towards the right host on the internal network. Normally the IDENT server on these hosts wouldn't answer queries from hosts != X and therefore the router has to fake the connection from X. Linux 2.4 doesn't have this behaviour. Setting ip_nonlocal_bind doesn't help. Maybe it could be done with some SNAT and libiptc & friends,... Maybe there is a simpler way. Does anyone know one? TIA, Zun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Tuesday 29 May 2001 10:37, elko wrote: > On Tuesday 29 May 2001 11:10, Alan Cox wrote: > > > It's not a bug. It's a feature. It only breaks systems that are run > > > w= ith "too > > > little" swap, and the only difference from 2.2 till now is, that the > > > de= finition > > > of "too little" changed. > > > > its a giant bug. Or do you want to add 128Gb of unused swap to a full > > kitted out Xeon box - or 512Gb to a big athlon ??? > > this bug is biting me too and I do NOT like it ! > > if it's a *giant* bug, then why is LK-2.4 called a *stable* kernel ?? This has been my complaint ever since the 2.2.0 kernel. I did not see a reasonably stable release until 2.2.12. I do not understand why code with such serious reproducible problems is being introduced into the even numbered kernels. What happened to the plan to use only the odd numbered kernels for debugging and refinement of the code? I never said anything because I thought the the kernel developers would eventually get back on track after the mistakes of the 2.2.x kernels but it has been years now and it still has not happened. I do not wish sound un-appreciative to those that have put so much wonderful work into the Linux kernel but this is the same thing we criticize Microsoft for. Putting out production code that obviously is not ready. Please lets not earn the same reputation of such commercial companies. By the way, The 2.4.5-ac3 kernel still fills swap and runs out of memory during my morning NFS incremental backup. I got this message in the syslog. May 29 06:39:15 (none) kernel: Out of Memory: Killed process 23502 (xteevee). For some reason xteevee is commonly the process that gets killed. My understanding is that it is part of Xscreensaver, but it was during my backup. This was the output of 'free' after I got up and found the swap completely full. By that time the memory was in a reasonable state but the swap space is still never being released. total used free sharedbuffers cached Mem:255960 220668 35292292 110960 80124 -/+ buffers/cache: 29584 226376 Swap:40124 40112 12 Configuration - AMD K6-2/450 256Mb RAM 2.4.5-ac3 Kernel compiled with egcs-1.1.2. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
share memory between kernel and user space
Hi, Is there any way to share a piece of memory which is allocated in kernel space with a user space program? (don't use copy_to_user etc.) Thanks, Alex -- Feng Xian _o) .~. (o_ /\\ /V\ //\ _\_V// \\ V_/_ /( )\ ^^-^^ ALEX - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] minor lockd debugging typo
Rather than print proc twice, you probably intend to show the prog.
(At least, I had wanted to see the prog in the debugging output. :) )
-- Pete
diff -X dontdiff -ruN linux-2.4.5-kdb/fs/lockd/mon.c linux-2.4.5/fs/lockd/mon.c
--- linux-2.4.5-kdb/fs/lockd/mon.c Mon Oct 16 15:58:51 2000
+++ linux-2.4.5/fs/lockd/mon.c Tue May 29 15:52:17 2001
@@ -146,7 +146,7 @@
u32 addr = ntohl(argp->addr);
dprintk("nsm: xdr_encode_mon(%08x, %d, %d, %d)\n",
- htonl(argp->addr), htonl(argp->proc),
+ htonl(argp->addr), htonl(argp->prog),
htonl(argp->vers), htonl(argp->proc));
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA KT133A Northbridge bug reported
On Tue, May 29, 2001 at 03:56:15PM +0200, Holger Lubitz wrote: > Translation: "As Stephan Schwolow from MSI Germany told Chip Online, the > problem with the VIA northbridge can be identified by a warm start from > DOS or a Windows reboot: If the screen stays black, the chip has an > error." > > As far as I understand it, the problem is only affecting "warm reboots". > And I couldn't care less about warm reboots - my machines usually run > 24/7 :) I have seen this problem sometimes. I don't read German though - does the page mention a fix? My machines usually run 24/7 too, but there's this little think called DRI which for some people works really nicely. Some of us are not as lucky though and in the meantime have problems with rebooting our machines. It seems that an ATX power off is not sufficient to get things going again, power must be cut to the main supply for a few seconds first. Thankfully my PSU has a real switch. -- Joseph Carter <[EMAIL PROTECTED]>Free software developer I sat laughing snidely into my notebook until they showed me a PC running Linux. And oh! It was as though the heavens opened and God handed down a client-side OS so beautiful, so graceful, and so elegant that a million Microsoft developers couldn't have invented it even if they had a hundred years and a thousand crates of Jolt cola. -- LAN Times PGP signature
linux-2.4.3-ac14 spinlock problem?
Hi,
I was running something on my Dell dual p3 box (optiplex gx300). my kernel
is linux-2.4.3-ac14. I got the following message:
__rwsem_do_wake(): wait_list unexpectedly empty
[4191] c5966f60 = { 0001 })
kenel BUG at rwsem.c:99!
invalid operand:
CPU:1
EIP:0010:[]
EFLAGS: 00010282
kenel BUG at /usr/src/2.4.3-ac14/include/asm/spinlock.h:104!
I upgrade the kernel to 2.4.5, no such problem any more.
Any idea?
Alex
--
Feng Xian
_o) .~. (o_
/\\ /V\ //\
_\_V// \\ V_/_
/( )\
^^-^^
ALEX
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
> In BSD, select() states that when a time out occurs, the bits passed to > select will not be altered. In Linux, which claims BSD compliancy for this Nope. BSD manual pages (the authentic ones anyway) say that the timeout value may well be written back but that this was a future enhancement and that users shoulsnt rely on the value being unchanged. > in the man page (but does not state either way what will happen to the > bits), zeros the users bit masks when a timeout occurs. I have written a > test case, and run on both systems; BSD behaves as stated, Linux does not > act like BSD. > > Should the man pages be changed to reflect reality, or select() fixed to > act like BSD? BSD should stop changing its mind if its changed its man pages - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][REPOST] Re: EXT2-fs error (device ide0(3,1)): read_inode_bitmap
You write:
> Ok, this is probabally old news and has been fixed, but
> the following happened in kernel 2.4.3 (ironically when i was deleting
> /usr/src/linux in order to extract the latest 2.4.5 :-)
Old news for me, fixed this bug in January, see:
http://marc.theaimsgroup.com/?l=linux-kernel=98339241223296=4
but the whole patch did not make it into the Linus kernel (not sure
if it is in -ac or not).
> However, it has a very slight sound of a more serious problem, to do with my
> disk (however, since i know nothing about this error message, i will take no
> sides)
However, there is still a problem in the ext2 code because it does not
clear the in-memory inode on the error paths. Patch below will fix.
Linus (and Alan, if needed), please apply.
> May 29 01:36:35 toweringmeep kernel: hda: read_intr: status=0x59 {
> DriveReady SeekComplete DataRequest Error }
> May 29 01:36:35 toweringmeep kernel: hda: read_intr: error=0x40 {
> UncorrectableError }, LBAsect=2113616, sector=2113553
> May 29 01:36:35 toweringmeep kernel: end_request: I/O error, dev 03:01
> (hda), sector 2113553
> May 29 01:36:35 toweringmeep kernel: EXT2-fs error (device ide0(3,1)):
> read_inode_bitmap: Cannot read inode bitmap - block_group = 129,
> inode_bitmap = 1056776
> May 29 01:36:35 toweringmeep kernel: kernel BUG at inode.c:886!
> is this a nice catch 22 ? or is there a nasty problem with one of my disks
> ... im about to reboot and check the disk
You have a disk problem, which caused I/O failure (the hda: read_intr
messages are first). Time for a backup (if you don't have one) and a
new disk.
Cheers, Andreas
===
--- linux-2.4.5.orig/fs/ext2/ialloc.c Tue Apr 10 16:44:49 2001
+++ linux-2.4.5-aed/fs/ext2/ialloc.cTue May 29 13:32:04 2001
@@ -199,10 +199,15 @@
lock_super (sb);
es = sb->u.ext2_sb.s_es;
- if (ino < EXT2_FIRST_INO(sb) ||
+ is_directory = S_ISDIR(inode->i_mode);
+
+ /* Do this BEFORE marking the inode not in use or returning an error */
+ clear_inode (inode);
+
+ if (ino < EXT2_FIRST_INO(sb) ||
ino > le32_to_cpu(es->s_inodes_count)) {
- ext2_error (sb, "free_inode",
- "reserved inode or nonexistent inode");
+ ext2_error (sb, "ext2_free_inode",
+ "reserved or nonexistent inode %lu", ino);
goto error_return;
}
block_group = (ino - 1) / EXT2_INODES_PER_GROUP(sb);
@@ -210,13 +215,8 @@
bitmap_nr = load_inode_bitmap (sb, block_group);
if (bitmap_nr < 0)
goto error_return;
-
+
bh = sb->u.ext2_sb.s_inode_bitmap[bitmap_nr];
-
- is_directory = S_ISDIR(inode->i_mode);
-
- /* Do this BEFORE marking the inode not in use */
- clear_inode (inode);
/* Ok, now we can actually update the inode bitmaps.. */
if (!ext2_clear_bit (bit, bh->b_data))
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: query regarding 'map_user_kiobuf'
[EMAIL PROTECTED] said: > After using the 'map_user_kiobuf', I observed the followiing: > > 1. 'kiobuf->maplist[0]->virtual' contains a different virtual address than > the user space buffer address > 2. But these two addresses are mapped as when i write something using the > address 'kiobuf->maplist[0]->virtual' inside the kernel, I see the same > data in the user space buffer in my application. > 3. I use the 'virt_to_phys' operation to the virtual address > 'kiobuf->maplist[0]->virtual' to get the physical address. > 4. I use this physical address for DMA operations. > > Now, using this information I do a DMA from card to system memory. What I > have noticed is that DMA happens somewhere else in the system memory. I am > not able to execute most of the commands (ls, chmod, cat, clear etc) after > my user program exits. > > Am I doing the steps 3 and 4 above right? After calling map_user_kiobuf(), I believe you should be locking the pages in memory by calling lock_kiovec(). Otherwise, nothing prevents them from being paged out again. Also, the pages may be in high memory and not directly accessible. You should use kmap() before touching them from the kernel rather than just using page->virtual, and obviously kunmap() afterwards. The PCI DMA interface is more complex than simply using virt_to_phys() too, if you want to deal correctly with the highmem case. I'm sure others will give you the details or pointers to the documentation. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems under 2.4.4/5
> "Mike" == Miquel van Smoorenburg <[EMAIL PROTECTED]> writes: Mike> In article <[EMAIL PROTECTED]>, Mike> Narayan Desai <[EMAIL PROTECTED]> wrote: >> Hi. I have started having serial console problems in the last bunch >> of kernel releases. I have tried various 2.4.4 and 2.4.5 ac kernels >> (up to and including 2.4.5-ac4) and the problem has persisted. The >> problem is basically that serial console doesn't recieve. Mike> The serial driver now pays attention to the CREAD bit. Sysvinit Mike> clears it, so that's where it goes wrong. Mike> I don't think this change should have gone into a 'stable' Mike> kernel version. 2.5.0 would have been fine, not 2.4.4 How would I go about resetting this so that serial console worked again? thanks... -nld - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: new aic7xxx oopses with AHA2940
>OK. Now I cut out the Oops out of my /var/log/messages, then did Can you provide the full dmesg from a working kernel for you system? I need to know the type of controller in use as well as some other system attributes. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems under 2.4.4/5
In article <[EMAIL PROTECTED]>, Narayan Desai <[EMAIL PROTECTED]> wrote: >Hi. I have started having serial console problems in the last bunch of >kernel releases. I have tried various 2.4.4 and 2.4.5 ac kernels (up >to and including 2.4.5-ac4) and the problem has persisted. The problem >is basically that serial console doesn't recieve. The serial driver now pays attention to the CREAD bit. Sysvinit clears it, so that's where it goes wrong. I don't think this change should have gone into a 'stable' kernel version. 2.5.0 would have been fine, not 2.4.4 Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] softirq-2.4.5-E5
the attached softirq-2.4.5-E5 patch (against 2.4.5-ac3) tries to solve all
softirq, tasklet and scheduling latency problems i could identify while
testing TCP latencies over gigabit connections. The list of problems, as
of 2.4.5-ac3:
- the need_resched check in the arch/i386/kernel/entry.S syscall/irq
return code has a race that makes it possible to miss a reschedule for
up to smp_num_cpus*HZ jiffies.
- the softirq check in entry.S has a race as well.
- on x86, APIC interrupts do not trigger do_softirq(). This is especially
problematic with the smptimers patch, which is APIC-irq driven.
- local_bh_disable() blocks the execution of do_softirq(), and it takes
a nondeterministic amount of time after local_bh_enable() for the next
do_softirq() to be triggered.
- do_softirq() does not execute softirqs that got activated meanwhile,
and the next do_softirq() run happens after a nondeterministic amount
of time.
- the tasklet design re-enables their driving softirq occasionally, which
makes 'complete' softirq processing impossible.
the patch (tries to) solve all these problems. The changes:
- all softirqs are guaranteed to be handled after do_softirq() returns
(even those which are activated during softirq run)
- softirq handling is immediately restarted if bhs are re-enabled again.
- the tasklet code got rewritten (but externally visible semantics are
kept) to not rely on marking the softirq busy. The new code is a bit
tricky, but it should be correct.
- some code got a bit slower, some code got a bit faster. I believe most
of the changes made the softirq/tasklet implementation clearer.
- some minor uninlining of too big inline functions, and other cleanup
was done as well.
- no global serialization was added to any part of the softirq or tasklet
code, so scalability is not impacted.
the patch is stable under every workload i tried, handles softirqs and
tasklets with the minimum possible latency, thus it maximizes cache
locality. The patch has no known bug, and the kernel has no known
lost-wakeup, lost-softirq problem i know of. TCP latencies and TCP
throughput is picture-perfect.
Comments?
Ingo
--- linux/kernel/softirq.c.orig Fri Dec 29 23:07:24 2000
+++ linux/kernel/softirq.c Tue May 29 17:41:14 2001
@@ -52,12 +52,12 @@
int cpu = smp_processor_id();
__u32 active, mask;
+ local_irq_disable();
if (in_interrupt())
- return;
+ goto out;
local_bh_disable();
- local_irq_disable();
mask = softirq_mask(cpu);
active = softirq_active(cpu) & mask;
@@ -71,7 +71,6 @@
local_irq_enable();
h = softirq_vec;
- mask &= ~active;
do {
if (active & 1)
@@ -82,12 +81,13 @@
local_irq_disable();
- active = softirq_active(cpu);
- if ((active &= mask) != 0)
+ active = softirq_active(cpu) & mask;
+ if (active)
goto retry;
}
- local_bh_enable();
+ __local_bh_enable();
+out:
/* Leave with locally disabled hard irqs. It is critical to close
* window for infinite recursion, while we help local bh count,
@@ -121,6 +121,45 @@
struct tasklet_head tasklet_vec[NR_CPUS] __cacheline_aligned;
+void tasklet_schedule(struct tasklet_struct *t)
+{
+ unsigned long flags;
+ int cpu;
+
+ cpu = smp_processor_id();
+ local_irq_save(flags);
+ /*
+* If nobody is running it then add it to this CPU's
+* tasklet queue.
+*/
+ if (!test_and_set_bit(TASKLET_STATE_SCHED, >state) &&
+ tasklet_trylock(t)) {
+ t->next = tasklet_vec[cpu].list;
+ tasklet_vec[cpu].list = t;
+ __cpu_raise_softirq(cpu, TASKLET_SOFTIRQ);
+ tasklet_unlock(t);
+ }
+ local_irq_restore(flags);
+}
+
+void tasklet_hi_schedule(struct tasklet_struct *t)
+{
+ unsigned long flags;
+ int cpu;
+
+ cpu = smp_processor_id();
+ local_irq_save(flags);
+
+ if (!test_and_set_bit(TASKLET_STATE_SCHED, >state) &&
+ tasklet_trylock(t)) {
+ t->next = tasklet_hi_vec[cpu].list;
+ tasklet_hi_vec[cpu].list = t;
+ __cpu_raise_softirq(cpu, HI_SOFTIRQ);
+ tasklet_unlock(t);
+ }
+ local_irq_restore(flags);
+}
+
static void tasklet_action(struct softirq_action *a)
{
int cpu = smp_processor_id();
@@ -129,37 +168,37 @@
local_irq_disable();
list = tasklet_vec[cpu].list;
tasklet_vec[cpu].list = NULL;
- local_irq_enable();
- while (list != NULL) {
+ while
Re: select() - Linux vs. BSD
On Tue, May 29, 2001 at 11:55:24AM -0400, John Chris Wren wrote:
> select will not be altered. In Linux, which claims BSD compliancy for this
> in the man page (but does not state either way what will happen to the
> bits), zeros the users bit masks when a timeout occurs. I have written a
Where in the man page does it state this? I just read it and couldn't find
any such statement.
I do, however, find the following:
exceptfds will be watched for exceptions. On exit, the
sets are modified in place to indicate which descriptors
actually changed status.
If there is a time out, it makes sense that no descriptors changed state,
and so everything would be zeroed out.
And actually, the example seems to support this:
if (retval)
printf("Data is available now.\n");
/* FD_ISSET(0, ) will be true. */
The comment seems to indicate that if retval is 0, then FD_ISSET will be
false.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[EMAIL PROTECTED] and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS with 2.4.5 [kernel BUG at inode.c:486]
On Tue, 29 May 2001, Gergely Tamas wrote: > Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says >c01c4020, System.map says c0154160. Ignoring ksyms_base entry > kernel BUG at inode.c:486! [snip] _Lovely_. NFS, apparently on revalidate path, doesn't care to hold on the unhashed inode until its pages are gone. Trond? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: console colors messed up with 2.4.X Rivafb driver
[EMAIL PROTECTED] writes: > I have a Riva128 based video card in a older SMP P-Pro system and with all > of the lastest 2.4 series of kernels (mostly the ac stuff) I have screwy colors > on the console (the penguin boot logos are shades of blue) and initially when > I start X (XFree86 4.0.3) the colors are very dark until I switch to a console I have this same problem with my Intel 810. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Spelling fix in slab.h
Hi! I know it is not important, but anyway: Pavel Index: slab.h === RCS file: /home/cvs/Repository/linux/include/linux/slab.h,v retrieving revision 1.1.1.2 diff -u -u -r1.1.1.2 slab.h --- slab.h 2001/04/19 20:00:39 1.1.1.2 +++ slab.h 2001/05/29 15:07:17 @@ -29,7 +29,7 @@ * The first 3 are only valid when the allocator as been build * SLAB_DEBUG_SUPPORT. */ -#defineSLAB_DEBUG_FREE 0x0100UL/* Peform (expensive) checks on free */ +#defineSLAB_DEBUG_FREE 0x0100UL/* Perform (expensive) checks +on free */ #defineSLAB_DEBUG_INITIAL 0x0200UL/* Call constructor (as verifier) */ #defineSLAB_RED_ZONE 0x0400UL/* Red zone objs in a cache */ #defineSLAB_POISON 0x0800UL/* Poison objects */ -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac4
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac4 o APIC parsing updates(Ingo Molnar) o Retry rather than losing I/O on an IDE DMA (Jens Axboe) timeout. o Add missing locking to cs46xx (Frank Davis) o Clean up sym53c416 and add PnP support (me) o Tidy up changelog in apm.c (Stephen Rothwell) o Update jffs2, remove abuse of kdev_t(David Woodhouse) o Fix oops on unplugging bluetooth(Greg Kroah-Hartmann) o Move stuff into bss on aironet4500 (Rasmus Andersen) o Fix up alpha oops output(George France) o Update SysKonnect PCI id list (Mirko Lindner) o Update SysKonnect GigE driver (Mirko Lindner) o Add ATM DS3/OC12 definitions to atmdev.h(Mitchell Blank) o Clean up atm drivers, fixed up user space (Mitchell Blank, access with irqs off, kmalloc and use after John Levon) free. o Update input device/joystick/gameport drivers (Vojtech Pavlik) o Update USB hid drivers (Vojtech Pavlik) o Fix out of memory oops in hysdn (Rasmus Andersen) o Belarussian should be Belarusian according to (Nerijus Baliunas) the standards o Support booting off old 720K floppies (Niels Jensen, Chris Noe) 2.4.5-ac3 o Ignore console writes from an IRQ handler (me) o Make SIGBUS/SIGILL visible to UML debugger (Jeff Dike) o Clean up UML syscalls add missing items (Jeff Dike) o Clean up non portable UML code (Jeff Dike) o Fix off by one and other oddments in hostfs (Henrik Nordstrom) o Update UML to use CONFIG_SMP not __SMP__(Jeff Dike) o Fix UML crash if console is typed at too early (Jeff Dike) o Clean up UML host transports(Lennert Buytenhek, Jim Leu) o Resynchronize UML/ppc (Chris Emerson) o Fix UML crash if it had an address space hole (Jeff Dike) between text and data o Fix rd_ioctl crash with initrd (Go Taniguchi) o Fix IRQ ack path on Alpha rawhide (Richard Henderson) o Drop back to older 8139too driver from 2.4.3 | Seems the new one causes lockups o Experimental promise fastrak raid driver(Arjan van de Ven) 2.4.5-ac2 o Restore lock_kernel on umount (Al Viro) | Should cure Reiserfs crash in 2.4.5 o Fix additional scsi_ioctl leak (John Martin) o Clean up scsi_ioctl error handling (me) o Configure.help typo fixes (Nerijus Baliunas) o Fix hgafb problems with logos (Ferenc Bakonyi) o Fix lock problems in the rio driver (Rasmus Andersen) o Make new cmpci SMP safe (Carlos E Gorges) o Fix missing restore flags in soundmodem (Rasmus Andersen) o Set max sectors in ps2esdi (Paul Gortmaker) o Fix interrupt restore problems in mixcom(Rasmus Andersen) o Fix alpha compile on dp264/generic (Andrea Arcangeli) o Fix irda irport locking restores(Rasmus Andersen) o Fix failed kmalloc handling in hisax(Kai Germaschewski) o Add missing memory barrier in qlogicisp (?) o Fix missing restore_flags in eata_dma (Rasmus Andersen) o Fix procfs locking in irttp (Rasmus Andersen) o Winbond updates (Manfred Spraul) o Stop network eating PF_MEMALLOC ram (Manfred Spraul) o Drop fs/buffer.c low mem flush changes (me) o Drop changes to mm/highmem.c(me) | I don't think the Linus one is quite right but its easier | for everyone to be working off one base o Revert GFP_FAIL and some other alloc bits (me) o Hopefully fix initrd problem(me) o Fix kmalloc check in ide-tape (Rasmus Andersen) o Fix irda irtty locking (Rasmus Andersen) o Fix missing irq restore in qla1280 (Rasmus Andersen) o Fix proc/pid/mem cross exec
query regarding 'map_user_kiobuf'
I am using linux kernel version 2.4.2 on Intel PC. I have been trying my luck for over a week regarding usage of 'map_user_kiobuf' for doing a DMA into a memory area that belongs to user space. Actually my requirement is that I want to do DMA into a user space memory area. What I have done through suggestions is that allocate memory in user space. I pass user space buffer address to a kernel module. Inside the kernel module, I use 'map_user_kiobuf' passing user space buffer address to it. After using the 'map_user_kiobuf', I observed the followiing: 1. 'kiobuf->maplist[0]->virtual' contains a different virtual address than the user space buffer address 2. But these two addresses are mapped as when i write something using the address 'kiobuf->maplist[0]->virtual' inside the kernel, I see the same data in the user space buffer in my application. 3. I use the 'virt_to_phys' operation to the virtual address 'kiobuf->maplist[0]->virtual' to get the physical address. 4. I use this physical address for DMA operations. Now, using this information I do a DMA from card to system memory. What I have noticed is that DMA happens somewhere else in the system memory. I am not able to execute most of the commands (ls, chmod, cat, clear etc) after my user program exits. Am I doing the steps 3 and 4 above right? Regards, Daljeet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
select() - Linux vs. BSD
I hope I'm not rehashing anything discussed before, but I couldn't find any references to this: In BSD, select() states that when a time out occurs, the bits passed to select will not be altered. In Linux, which claims BSD compliancy for this in the man page (but does not state either way what will happen to the bits), zeros the users bit masks when a timeout occurs. I have written a test case, and run on both systems; BSD behaves as stated, Linux does not act like BSD. Should the man pages be changed to reflect reality, or select() fixed to act like BSD? -- John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Console display in portrait mode with unusual dpi resolution
Hi! > Overview: At business I just got a brand new EIZO 18" LCD display L675 > to test its usability for working in portrait mode to show a full A4 > page. These test were done on Windows NT4 but I'd really like to know > how well Linux would have done. I'm going to describe all the obstacles > I encountered on Windows so anybody may knows the corresponding answers > for Linux. Maybe there are other problems on Linux? > > 1. Obstacle > While the EIZO L675 is mechanically turnable, it doesn't handle the > landscape/portrait mode switch itself. [OFFTOPIC] Are the any other > displays capable of this? [OFFTOPIC OFF] The turning software had to be > ordered/paid separate (Pivot software). Of course the display should > handle it itself, but until this happens a software solution is okay. Is > there any software solution for Linux? > I've heard there are graphics cards which handles the landscape/portrait > mode themselves (i.e. ATI radeon). This is almost as good as if the > display handles it, as long as if there are the corresponding drivers > available. How about Linux drivers? > PS. My good old monochrome portrait monitor from Apple (around 1990) is > an fine example. Things like iPAQ can do portrait/landscape switch, and it is handled by modified Xserver. Agenda people will probably have similar hack. Warning: it is going to be slow, and don't dream to use DRI. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
EXT2-fs error (device ide0(3,1)): read_inode_bitmap: Cannot read inode bitmap - block_group = 129, inode_bitmap = 1056776 , kernel BUG at inode.c:886!
BlankTo all the kernel people,
Ok, this is probabally old news and has been fixed, but
the following happened in kernel 2.4.3 (ironically when i was deleting
/usr/src/linux in order to extract the latest 2.4.5 :-)
Here it is:
However, it has a very slight sound of a more serious problem, to do with my
disk (however, since i know nothing about this error message, i will take no
sides)
May 29 01:36:35 toweringmeep kernel: hda: read_intr: status=0x59 {
DriveReady SeekComplete DataRequest Error }
May 29 01:36:35 toweringmeep kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=2113616, sector=2113553
May 29 01:36:35 toweringmeep kernel: end_request: I/O error, dev 03:01
(hda), sector 2113553
May 29 01:36:35 toweringmeep kernel: EXT2-fs error (device ide0(3,1)):
read_inode_bitmap: Cannot read inode bitmap - block_group = 129,
inode_bitmap = 1056776
May 29 01:36:35 toweringmeep kernel: kernel BUG at inode.c:886!
May 29 01:36:35 toweringmeep kernel: invalid operand:
May 29 01:36:35 toweringmeep kernel: CPU:0
May 29 01:36:35 toweringmeep kernel: EIP:0010:[iput+218/348]
May 29 01:36:35 toweringmeep kernel: EFLAGS: 00010282
May 29 01:36:35 toweringmeep kernel: eax: 001b ebx: c04e12a0 ecx:
c1c8e000 edx: c0229808
May 29 01:36:35 toweringmeep kernel: esi: c022d440 edi: c1ca9f40 ebp:
c10e1fa4 esp: c10e1f50
May 29 01:36:35 toweringmeep kernel: ds: 0018 es: 0018 ss: 0018
May 29 01:36:35 toweringmeep kernel: Process rm (pid: 5838,
stackpage=c10e1000)
May 29 01:36:35 toweringmeep kernel: Stack: c01f11e5 c01f1265 0376
c1ca9f40 c04e12a0 c013b9a8 c04e12a0
May 29 01:36:35 toweringmeep kernel:c04e10c0 c0135854 c1ca9f40
c1ca9f40 c1ca9f40 c1a05000 c013592b c04e10c0
May 29 01:36:35 toweringmeep kernel:c1ca9f40 c10e 08097753
b838 c0779540 c10ed7a0 c1a05000
May 29 01:36:35 toweringmeep kernel: Call Trace: [d_delete+76/108]
[vfs_unlink+276/324] [sys_unlink+167/284] [system_call+51/64]
May 29 01:36:35 toweringmeep kernel:
May 29 01:36:35 toweringmeep kernel: Code: 0f 0b 83 c4 0c eb 6f 39 1b 74 3b
f6 83 f0 00 00 00 07 75 26
Incidently, could anyone tell me out of interest what the problem actually
is / was ?
Thanks
Dave
PS: im now having a problem extracting the new kernel and find i have
numerous of these
May 29 01:53:35 toweringmeep kernel: hda: read_intr: status=0x59 {
DriveReady SeekComplete DataRequest Error }
May 29 01:53:35 toweringmeep kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=2113616, sector=2113553
May 29 01:53:35 toweringmeep kernel: end_request: I/O error, dev 03:01
(hda), sector 2113553
May 29 01:53:35 toweringmeep kernel: EXT2-fs error (device ide0(3,1)):
read_inode_bitmap: Cannot read inode bitmap - block_group = 129,
inode_bitmap = 1056776
is this a nice catch 22 ? or is there a nasty problem with one of my disks
... im about to reboot and check the disk
---
The information in this e-mail and any files sent with it is confidential to
the ordinary user of the e-mail address to which it was addressed and may
also be legally privileged. It is not to be relied upon by any person other
than the addressee except with the sender's prior written approval. If no
such approval is given, the sender will not accept liability (in negligence
or otherwise) arising from any third party acting, or refraining from
acting, on such information. If you are not the intended recipient of this
e-mail you may not copy, forward, disclose or otherwise use it or any part
of it in any form whatsoever. If you have received this e-mail in error
please notify the sender immediately, destroy any copies and delete it from
your computer system. Have a nice Day !
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] I/O scheduler starvation
Hi,
Going over this a bit, an deviant from the original design of
elevator_linus seems to have snuck in. Well, almost, I've been aware of
this for some time...
The idea was _not_ to account request merges, since they will (in by far
the most cases) incur the cost of a seek. Instead we just account seeks,
any seek (and please don't start a debate on short vs long seeks again,
I'm not listening). The attached patch corrects this, and also corrects
the initial sequence numbers (typically this would be sequence / 8
number of seeks allowed to pass a request now).
I'll do some formal timing on this later.
--
Jens Axboe
--- drivers/block/ll_rw_blk.c~ Tue May 29 17:53:58 2001
+++ drivers/block/ll_rw_blk.c Tue May 29 17:54:38 2001
@@ -742,7 +742,6 @@
case ELEVATOR_BACK_MERGE:
if (!q->back_merge_fn(q, req, bh, max_segments))
break;
- elevator->elevator_merge_cleanup_fn(q, req, count);
req->bhtail->b_reqnext = bh;
req->bhtail = bh;
req->nr_sectors = req->hard_nr_sectors += count;
@@ -754,7 +753,6 @@
case ELEVATOR_FRONT_MERGE:
if (!q->front_merge_fn(q, req, bh, max_segments))
break;
- elevator->elevator_merge_cleanup_fn(q, req, count);
bh->b_reqnext = req->bh;
req->bh = bh;
req->buffer = bh->b_data;
@@ -775,8 +773,10 @@
* request. if no hints, just add it to the back
* of the queue
*/
- if (req)
+ if (req) {
insert_here = >queue;
+ elevator->elevator_merge_cleanup_fn(q, req, count);
+ }
break;
default:
--- drivers/block/elevator.c~ Tue May 29 17:54:03 2001
+++ drivers/block/elevator.cTue May 29 17:59:28 2001
@@ -110,7 +110,6 @@
break;
} else if (__rq->sector - count == bh->b_rsector) {
ret = ELEVATOR_FRONT_MERGE;
- __rq->elevator_sequence -= count;
*req = __rq;
break;
}
@@ -126,10 +125,10 @@
/*
* second pass scan of requests that got passed over, if any
*/
- while ((entry = entry->next) != head) {
+ do {
struct request *tmp = blkdev_entry_to_request(entry);
tmp->elevator_sequence -= count;
- }
+ } while ((entry = entry->next) != head);
}
void elevator_linus_merge_req(struct request *req, struct request *next)
--- include/linux/elevator.h~ Tue May 29 17:54:10 2001
+++ include/linux/elevator.hTue May 29 17:55:25 2001
@@ -93,8 +93,8 @@
#define ELEVATOR_LINUS \
((elevator_t) {\
- 8192, /* read passovers */\
- 16384, /* write passovers */ \
+ 1024, /* read passovers */\
+ 4096, /* write passovers */ \
\
elevator_linus_merge, /* elevator_merge_fn */ \
elevator_linus_merge_cleanup, /* elevator_merge_cleanup_fn */ \
Re: [Linux-ntfs] Re: [Linux-NTFS-Dev] Re: ANN: NTFS new release available (1.1.15)
On Tue, May 29, 2001 at 10:18:41AM +0200, Martin von Loewis wrote: > > > Anyone know about 3.1? > > > > > > > It's an HPFS variant. > > No. NT was using NTFS right from the start. > > Regards, > Martin No. They were not. Their first cuts of NT used an HPFS variant until NTFS could be completed. The guy who wrote NTFS for MS was a consultant for us for several years, and I got a very long briefing on the history of NT file systems over the years. I do not know which version was the cutover, but I do believe it was pre 3.X NT versions. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Promise Ultra 100 TX2
#Include I just bought one of $subject (PDC 20268) Removed a Ultra 66 from my system and plugged the new one into the 66Mhz PCI-Bus (Intependent from the 33Mhz PCI-Bus (Tyan Thunder HE-SL Mainboard with Serverworks HE-SL-Chipset)) Kernel is 2.4.4 with Promise support compiled in. (The Ultra 66 works like a charm with this kernel) But the new controller wasn't deteced by the IDE-Subsystem AT ALL. (It only showed the onboard OSB4-Adapter) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unresolved symbols printk ?
On Tue, 29 May 2001 15:54:36 +0200, Nico Schottelius <[EMAIL PROTECTED]> wrote: >Just a small question, what could be the reason I have a broken >Makefile ? >This seems to happen frequently, if there is a need >to name it into the lkml. I am surprised >a makefile gets screwed up ? It is the makefile design for modversions that is broken. The entire makefile system is being redesigned and rewritten from scratch for kernel 2.5. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with minor devices numbers in 2.4.4/68k
Hopefully, I don't offend anyone by asking this here, but
I assume (perhaps incorrectly) that this is the place to
go when trying to decipher writing device drivers.
My problem: A device driver for a custom board worked fine
under 2.2.10 - I used the minor number to identify various
channels on the board. In the open() call, I used
MINOR(inode->i_rdev) to decode that information. Now under
2.4.4, this *appears* to be broken - though I am certain it
is my misunderstanding. In checking, every minor device
returns exactly the same i_rdev code.
Anyway, attached are some snippets of code, if someone can point
out where I goofed, I would really appreciate it. I'm in the
process of trying to prove to the PHB that linux is a viable
embedded platform.
Note that at this time, I am not using the devfs, though I did
try and incorporate support. If someone can point me to a good
"how do deal with the changes in 2.4" I'd appreciate that as well.
Anyway in my init_module() routine I register the region, and major/minor
devices:
if((devfs_register_chrdev(42,"timer", _fops)) < 0)
{
printk("Timer: bad doobie, device 42 missing?\n");
return -EIO;
}
else
{
int tmrs;
printk("Timer: Cool,chrdev is regsitered!\n");
for(tmrs=0;tmrs<8;tmrs++)
{
timer_handles[tmrs]=devfs_register(NULL,"timer",DEVFS_FL_DEFAULT,
42, tmrs, S_IFCHR |
S_IRUGO | S_IWUSR,_fops,tmrs);
}
}
And in my open, I try to decode the minor number:
static
int timer_open(struct inode *inode, struct file *file)
{
printk("sysclk: open() f_mode=%d, minor = %1d, minor2 %0x\n",
file->f_mode, MINOR(inode->i_rdev),(inode->i_rdev));
// we're going to be sneaky here - the minor number
// stored in the file private data will be used to
// index the 'interrupt occurred' flag for the poll
// routine.
file->private_data = (void *)MINOR(inode->i_rdev);
usequeue[MINOR(inode->i_rdev)]++;
MOD_INC_USE_COUNT;
return 0;
}
But MINOR(inode->i_rdev) always returns 0, no matter which
minor devices I open.
If this doesn't belong here, please direct mail me, as this
has my stymied.
Thank you.
--
Michael Baumann Optivus Technology Inc.|Loma Linda University Medical
Center
San Bernardino, California. (909)799-8308 |Internet: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM...
On Tuesday 29 May 2001 11:10, Alan Cox wrote: > > It's not a bug. It's a feature. It only breaks systems that are run w= > > ith "too > > little" swap, and the only difference from 2.2 till now is, that the de= > > finition > > of "too little" changed. > > its a giant bug. Or do you want to add 128Gb of unused swap to a full > kitted out Xeon box - or 512Gb to a big athlon ??? this bug is biting me too and I do NOT like it ! if it's a *giant* bug, then why is LK-2.4 called a *stable* kernel ?? -- Elko Holl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
console colors messed up with 2.4.X Rivafb driver
I have a Riva128 based video card in a older SMP P-Pro system and with all of the lastest 2.4 series of kernels (mostly the ac stuff) I have screwy colors on the console (the penguin boot logos are shades of blue) and initially when I start X (XFree86 4.0.3) the colors are very dark until I switch to a console and back again. Once I switch to a console and back to X things are fine in X. I noticed a reply to a note from Louis Garcia <[EMAIL PROTECTED]> by Bakonyi Ferenc <[EMAIL PROTECTED]> with some info about TNT cards expecting 8 bit verses 6 bit color registers. Bakonyi indicated that the console colors should be correct with Rivafb 0.9.2 and above but with the 2.4.5-ac3 kernel the boot messages indicate: rivafb: RIVA MTRR set to ON Console: switching to colour frame buffer device 160x64 rivafb: PCI nVidia NV3 framebuffer ver 0.9.2a (RIVA-128, 4MB @ 0xEF00) My /proc/pci entry says: Bus 0, device 15, function 0: VGA compatible controller: NVidia / SGS Thomson (Joint Venture) Riva128 (rev 16). IRQ 19. Master Capable. Latency=64. Min Gnt=3.Max Lat=1. Non-prefetchable 32 bit memory at 0xee00 [0xeeff]. Prefetchable 32 bit memory at 0xef00 [0xefff]. and even at 0.9.2a colors are still screwy on the console both before and after starting the Xserver. The fbset output on this system says: mode "1280x1024-74" # D: 135.007 MHz, H: 78.859 kHz, V: 74.116 Hz geometry 1280 1024 1280 1024 16 timings 7407 256 32 34 3 144 3 accel true rgba 5/11,6/5,5/0,0/0 endmode The same thing still occurs if I set the color depth to 8 bit. This is a pci card with 4Mb of video memory. I also have a AMD K6 system with a 16Mb AGP TNT2 card and this does not happen on that machine. BTW, why is the mtrr for the Riva set to 0M ??? -- Steven A. DuChene [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.mindspring.com/~sduchene/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 locks up on SMP - tcp-hang patch NOT fixed the problem!
> " " == dobos s <[EMAIL PROTECTED]> writes: > I have the problem. As I read mails between Alan, Ioan and > Trond on the above subject I decided to try Trond's tcp-hang > patch to see It really solves the problem. > I dont think so. In my source tree there are not compiled files > in net/sunrpc dir, and CONFIG_SUNRPC is not set in my .config! That patch was only meant to fix a hang in NFS and friends. It's doesn't fix anything in the generic TCP code. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Status of ALi MAGiK 1 support in 2.4.?
On Tue, May 29, 2001 at 05:18:39AM +0600, Bobby D. Bryant wrote: > sailing ever since. The only problems that I'm are ware of are a > (maybe) DMA problem and a (maybe) SMBus problem, per below. Right now I noticed the Win32 benchmark/test application Sandra mentioned an SMBus problem with the A7A266 as well. I have yet to try lm_sensors myself, but it looks like I won't get far. > May 22 21:45:07 pollux kernel: ALI15X3: IDE controller on PCI bus 00 dev > 20 > May 22 21:45:07 pollux kernel: PCI: No IRQ known for interrupt pin A of > device 00:04.0. Please try using pci=biosirq. I get the same message, but it does not appear to dramatically affect my performance. As I mentioned, I am getting 25MB/s (through hdparm; I have yet to try anything more) with my Quantum Fireball. My DMA is enabled in the BIOS and detected by the kernel. > The routing to IQR 0 sounds funny to me, but this is already way beyond > what I understand. Do you have the PnP operating system setting in the BIOS turned off? (ie. telling the BIOS you have non-PnP aware O/S) I noticed that prior to doing this, all of my PCI cards were listed as IRo 0. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] 4GB I/O, cut three
Hi, Another day, another version. Bugs fixed in this version: none Known bugs in this version: none In other words, it's perfect of course. Changes: - Added ide-dma segment coalescing - Only print highmem I/O enable info when HIGHMEM is actually set Please give it a test spin, especially if you have 1GB of RAM or more. You should see something like this when booting: hda: enabling highmem I/O ... SCSI: channel 0, id 0: enabling highmem I/O depending on drive configuration etc. Plea to maintainers of the different architectures: could you please add the arch parts to support this? This includes: - memory zoning at init time - page_to_bus - pci_map_page / pci_unmap_page - set_bh_sg - KM_BH_IRQ (for HIGHMEM archs) I think that's it, feel free to send me questions and (even better) patches. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA KT133A Northbridge bug reported
"Dr S.M. Huen" proclaimed: > I saw a report on AMDZone of another VIA chipset bug. The original source > is:- > http://www.chip.de/news_stories/news_stories_163106.html > > The claim from AMDZone's translation is that:- > " According to the report KT133A boards with chipset codes of 1EA0 and > 1EA4 can have the bug which causes your computer to restart." This seems like a translation error. The german original reads "Eigentlich für C-Athlons ausgelegt, produziert die Northbridge VT8363A Restart-Probleme mit genau dieser CPU." which roughly translates to "Originally intended for C-Athlons, the Northbridge VT8363A causes restart problems with exactly this CPU." The original article goes on with "Wie Stephan Schwolow von MSI Deutschland gegenüber CHIP Online mitteilte, lässt sich das Problem mit der VIA-Northbridge anhand eines Warmstarts aus dem DOS-Modus oder einem Windows-Neustart identifizieren: Bleibt der Bildschirm schwarz, hat der Chip einen Fehler." Translation: "As Stephan Schwolow from MSI Germany told Chip Online, the problem with the VIA northbridge can be identified by a warm start from DOS or a Windows reboot: If the screen stays black, the chip has an error." As far as I understand it, the problem is only affecting "warm reboots". And I couldn't care less about warm reboots - my machines usually run 24/7 :) Holger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unresolved symbols printk ?
> On Mon, May 28, 2001 at 07:00:39PM +0200, Nico Schottelius wrote: > > I am having problems with loading modules: > > I always get the unresolved symbols message. > > I didn't find any documentation for that, can you help me ? > > You did read question 8.8 from the linux-kernel mailing list FAQ? > > http://www.tux.org/lkml/#s8-8 Right now, yes :) Just a small question, what could be the reason I have a broken Makefile ? This seems to happen frequently, if there is a need to name it into the lkml. I am surprised a makefile gets screwed up ? Nico - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
