Re: [patch] serial console vs NMI watchdog
On Sun, 11 Mar 2001, Keith Owens wrote: > kdb has to completely disable the nmi counter while it is in control. > All interrupts are disabled, all but one cpus are spinning, the > control cpu does busy wait while it polls the input devices. With > that model there is no alternative to a complete disable. it sure has an alternative. The 'cpus spinning' code calls touch_nmi() within the busy loop, the polling code on the control CPU too. This is sure more robust and catches lockup bugs in kdb too ... 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: [patch] serial console vs NMI watchdog
On Sun, 11 Mar 2001 08:44:24 +0100 (CET), Ingo Molnar <[EMAIL PROTECTED]> wrote: >Andrew, > >your patch looks too complex, and doesnt cover the case of the serial >driver deadlocking. Why not add a "touch_nmi_watchdog_counter()" function >that just changes last_irq_sums instead of adding locking? This way >deadlocks will be caught in the serial code too. (because touch_nmi() will >only "postpone" the NMI watchdog lockup event, not disable it.) kdb has to completely disable the nmi counter while it is in control. All interrupts are disabled, all but one cpus are spinning, the control cpu does busy wait while it polls the input devices. With that model there is no alternative to a complete disable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] serial console vs NMI watchdog
On Sun, 11 Mar 2001 08:53:40 +0100 (CET), Ingo Molnar <[EMAIL PROTECTED]> wrote: >it sure has an alternative. The 'cpus spinning' code calls touch_nmi() >within the busy loop, the polling code on the control CPU too. This is >sure more robust and catches lockup bugs in kdb too ... Works for me. It even makes kdb simpler. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] serial console vs NMI watchdog
Andrew, your patch looks too complex, and doesnt cover the case of the serial driver deadlocking. Why not add a "touch_nmi_watchdog_counter()" function that just changes last_irq_sums instead of adding locking? This way deadlocks will be caught in the serial code too. (because touch_nmi() will only "postpone" the NMI watchdog lockup event, not disable it.) This should be a matter of 5 lines ... 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: 2.4.3pre1: kernel BUG at page_alloc.c:73!
Yeah, after looking more closely I noticed (nvrmapi.lib), i've only had two lockups ever with it .. er in 2d at least (in 6 months), today and yesterday, kinda weird :) On Sunday, 11 March 2001, at 18:19:57 (+1100), Keith Owens wrote: > That is just the glue code that nvidia uses to fool people. The kernel > module just creates a device that the main nvidia driver abuses to > bypass all the kernel checks. The real code is a 2M binary only blob. -- David Raufeisen <[EMAIL PROTECTED]> Cell: (604) 818-3596 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.3pre1: kernel BUG at page_alloc.c:73!
>On Suday, 11 March 2001, at 17:54:23 (+1100), >Keith Owens wrote: >> Bug caused by binary only driver. Complain to nvidia, not linux-kernel. On Sat, 10 Mar 2001 23:12:50 -0800, David Raufeisen <[EMAIL PROTECTED]> wrote: >Well, the kernel module is open source.. That is just the glue code that nvidia uses to fool people. The kernel module just creates a device that the main nvidia driver abuses to bypass all the kernel checks. The real code is a 2M binary only blob. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: List of recent (2.4.0 to 2.4.2-ac18) CONFIG options needing Configure.help text.
On Sun, 11 Mar 2001 02:08:15 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: >Keith Owens wrote: >> >> On Sat, 10 Mar 2001 23:03:19 -0700, >> Steven Cole <[EMAIL PROTECTED]> wrote: >> >With the 2.4.0 kernel, there were 476 CONFIG options which had >> >no help entry in Configure.help. With 2.4.2-ac18, this number is now 547, >> >which has been kept this low with 54 options getting Configure.help text. >> >> If any of these CONFIG_ options are always derived (i.e. the user never >> sees them on a config menu) then please add the suffix _DERIVED to such >> options. They still need to start with CONFIG_ to suit the kernel >> build dependency generator so we cannot change the start of the name. >> Appending _DERIVED will make it obvious that the options require no >> help text. > >Yow. That is very cumbersome. Can't you just keep a list somewhere, >instead of making such options longer? Not if we want to automate it for new options. Besides it makes a nice distinction in the code between user selectable options and options that config has worked out for itself. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.3pre1: kernel BUG at page_alloc.c:73!
Well, the kernel module is open source.. On Suday, 11 March 2001, at 17:54:23 (+1100), Keith Owens wrote: > On Sat, 10 Mar 2001 22:14:27 -0800, > David Raufeisen <[EMAIL PROTECTED]> wrote: > >Mar 10 21:34:30 prototype kernel:[free_pages+36/48] >[NVdriver:osFreeContigPages+79/84] [] [NVdriver:RmTeardownAGP+156/176] >[] [NVdriver:nv_devices+0/384] [NVdriver:nvExtEscape+2888/3100] [< > > Bug caused by binary only driver. Complain to nvidia, not linux-kernel. -- David Raufeisen <[EMAIL PROTECTED]> Cell: (604) 818-3596 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: List of recent (2.4.0 to 2.4.2-ac18) CONFIG options needing Configure.help text.
Keith Owens wrote: > > On Sat, 10 Mar 2001 23:03:19 -0700, > Steven Cole <[EMAIL PROTECTED]> wrote: > >With the 2.4.0 kernel, there were 476 CONFIG options which had > >no help entry in Configure.help. With 2.4.2-ac18, this number is now 547, > >which has been kept this low with 54 options getting Configure.help text. > > If any of these CONFIG_ options are always derived (i.e. the user never > sees them on a config menu) then please add the suffix _DERIVED to such > options. They still need to start with CONFIG_ to suit the kernel > build dependency generator so we cannot change the start of the name. > Appending _DERIVED will make it obvious that the options require no > help text. Yow. That is very cumbersome. Can't you just keep a list somewhere, instead of making such options longer? -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 lock contention and scalability
Hi,
> In the slow path of a spinlock_acquire they busy wait for a few
> cycles, and then call schedule with a zero timeout assuming that
> it'll basically do the same as a sched_yield() but more portably.
The obvious problem with this is that we bounce in and out of schedule()
a few times before moving on to the next task. I see this also with
sched_yield().
I had this patch lying around which I think came about when I was playing
with pthreads (which for spinlocks does sched_yield() for a while before
sleeping)
--- linux/kernel/sched.cFri Mar 9 10:26:56 2001
+++ linux_intel/kernel/sched.c Fri Mar 9 08:42:39 2001
@@ -505,6 +505,9 @@
goto out_unlock;
}
#else
+ if (prev->policy & SCHED_YIELD)
+ prev->counter = (prev->counter >> 4);
+
prev->policy &= ~SCHED_YIELD;
#endif /* CONFIG_SMP */
}
Anton
/* test sched_yield */
#include
#include
#include
#include
#include
#undef USE_SELECT
void waste_time()
{
int i;
for(i = 0; i < 1; i++)
;
}
void do_stuff(int i)
{
#ifdef USE_SELECT
struct timeval tv;
#endif
while(1) {
fprintf(stderr, "%d\n", i);
waste_time();
#ifdef USE_SELECT
tv.tv_sec = 0;
tv.tv_usec = 0;
select(0, NULL, NULL, NULL, &tv);
#else
sched_yield();
#endif
}
}
int main()
{
int i, pid;
for(i = 0; i < 10; i++) {
pid = fork();
if (!pid)
do_stuff(i);
}
do_stuff(i+1);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: List of recent (2.4.0 to 2.4.2-ac18) CONFIG options needing Configure.help text.
On Sat, 10 Mar 2001 23:03:19 -0700, Steven Cole <[EMAIL PROTECTED]> wrote: >With the 2.4.0 kernel, there were 476 CONFIG options which had >no help entry in Configure.help. With 2.4.2-ac18, this number is now 547, >which has been kept this low with 54 options getting Configure.help text. If any of these CONFIG_ options are always derived (i.e. the user never sees them on a config menu) then please add the suffix _DERIVED to such options. They still need to start with CONFIG_ to suit the kernel build dependency generator so we cannot change the start of the name. Appending _DERIVED will make it obvious that the options require no help text. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.3pre1: kernel BUG at page_alloc.c:73!
On Sat, 10 Mar 2001 22:14:27 -0800, David Raufeisen <[EMAIL PROTECTED]> wrote: >Mar 10 21:34:30 prototype kernel:[free_pages+36/48] >[NVdriver:osFreeContigPages+79/84] [] [NVdriver:RmTeardownAGP+156/176] >[] [NVdriver:nv_devices+0/384] [NVdriver:nvExtEscape+2888/3100] [< Bug caused by binary only driver. Complain to nvidia, not linux-kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel lock contention and scalability
Hi, > Thanks for looking into postgresql/pgbench related locking. Yes, > apparently postgresql uses a synchronization scheme that uses select() > to effect delays for backing off while attempting to acquire a lock. > However, it seems to me that runqueue lock contention was not entirely due > to postgresql code, since it was largely alleviated by the multiqueue > scheduler patch. Im not saying that the multiqueue scheduler patch isn't needed, just that this test case is caused by a bug in postgres. We shouldn't run around fixing symptoms - dropping the contention in the runqueue lock might not change the overall performance of the benchmark, on the other hand fixing the spinlocks in postgres probably will. On the other hand, if postgres still pounds on the runqueue lock after the bug has been fixed then we need to look at the multiqueue patch. Cheers, Anton - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.3pre1: kernel BUG at page_alloc.c:73!
Mar 10 21:34:30 prototype kernel: kernel BUG at page_alloc.c:73! Mar 10 21:34:30 prototype kernel: invalid operand: Mar 10 21:34:30 prototype kernel: CPU:0 Mar 10 21:34:30 prototype kernel: EIP:0010:[__free_pages_ok+34/784] Mar 10 21:34:30 prototype kernel: EFLAGS: 00013082 Mar 10 21:34:30 prototype kernel: eax: 001f ebx: c14285d0 ecx: c3642000 edx: c7839380 Mar 10 21:34:30 prototype kernel: esi: cfa7 edi: 001f ebp: 0003 esp: c3643c68 Mar 10 21:34:30 prototype kernel: ds: 0018 es: 0018 ss: 0018 Mar 10 21:34:30 prototype kernel: Process X (pid: 6847, stackpage=c3643000) Mar 10 21:34:30 prototype kernel: Stack: c021c565 c021c6f3 0049 cfa7 001f c3643cbc c0112c37 Mar 10 21:34:30 prototype kernel:cda57000 c88ce837 cda57000 e000 c012af3a c012af64 c88ce933 cda1d004 Mar 10 21:34:30 prototype kernel:c51aea40 c0044646 0305 c3643cd0 c3643cd0 c3643cd0 c88d6dc4 cfa7 Mar 10 21:34:30 prototype kernel: Call Trace: [] [iounmap+23/32] [] [NVdriver:osUnmapKernelSpace+67/76] [] [] [__free_pages+26/32] Mar 10 21:34:30 prototype kernel:[free_pages+36/48] [NVdriver:osFreeContigPages+79/84] [] [NVdriver:RmTeardownAGP+156/176] [] [NVdriver:nv_devices+0/384] [NVdriver:nvExtEscape+2888/3100] [< cda1d004>] Mar 10 21:34:30 prototype kernel:[] [] [NVdriver:_nv_rmsym_01225+71/104] [] [] [] [NVdriver:_nv_rmsym_01425+446/468] [] Mar 10 21:34:30 prototype kernel:[] [] [NVdriver:_nv_rmsym_00560+222/432] [] [] [NVdriver:nv_devices+0/384] [] [] Mar 10 21:34:30 prototype kernel:[alloc_skb+230/384] [sock_def_readable+38/80] [] [] [] [NVdriver:_nv_rmsym_00958+116/168] [] [] Mar 10 21:34:30 prototype kernel:[NVdriver:_nv_rmsym_00345+0/204] [] [NVdriver:_nv_rmsym_01083+293/776] [] [] [NVdriver:nv_ioctl+449/480] [NVdriver:nv_devices+0/384] [__run_task_q ueue+76/96] Mar 10 21:34:30 prototype kernel:[] [NVdriver:nv_bottom_halves+0/2560] [NVdriver:nv_bottom_halves+0/2560] [schedule+614/912] [sys_ioctl+359/384] [system_call+51/56] Mar 10 21:34:30 prototype kernel: Mar 10 21:34:30 prototype kernel: Code: 0f 0b 83 c4 0c 83 7b 08 00 74 16 6a 4b 68 f3 c6 21 c0 68 65 Linux prototype 2.4.3-pre1 #1 Sun Mar 4 14:14:54 PST 2001 i686 unknown Gnu C 2.95.3 Gnu make 3.79.1 binutils 2.10.91.0.2 util-linux 2.11 modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0b Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.58 Kbdcommand Sh-utils 2.0.11 Modules Loaded NVdriver reiserfs is the filesystem.. machine is athlon thunderbird 800mhz. -- David Raufeisen <[EMAIL PROTECTED]> Cell: (604) 818-3596 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
List of recent (2.4.0 to 2.4.2-ac18) CONFIG options needing Configure.help text.
Hello all, With the 2.4.0 kernel, there were 476 CONFIG options which had no help entry in Configure.help. With 2.4.2-ac18, this number is now 547, which has been kept this low with 54 options getting Configure.help text. The bottom line is that since 2.4.0, there are 125 new CONFIG options with no Configure.help text. One obvious point: there are some options which don't need Configure.help text, but if you're responsible for that option, I'm sure you'll be aware of which of your options are in that category. If you see any of _your_ options in the list below, please consider making a patch for Configure.help for your CONFIG option. Or, you can send me the information and I'll make the patch. Steven CONFIG_3270 CONFIG_3270_CONSOLE CONFIG_8xx_CONS_SMC2 CONFIG_ADVANTECH_WDT CONFIG_BLK_DEV_MPC8xx_IDE CONFIG_BLK_DEV_Q40IDE CONFIG_BLK_DEV_XPRAM CONFIG_COBALT_28 CONFIG_COBALT_MICRO_SERVER CONFIG_DEBUG_PORT0 CONFIG_DEBUG_PORT1 CONFIG_DEBUG_PORT2 CONFIG_DEBUG_PORT3 CONFIG_DEBUG_PORT_NULL CONFIG_DN_SERIAL CONFIG_ETRAX100LX CONFIG_ETRAX100LX_V2 CONFIG_ETRAX_9000_LEDS CONFIG_ETRAX_AXISFLASHMAP CONFIG_ETRAX_ETHERNET CONFIG_ETRAX_FLASH_BUSWIDTH CONFIG_ETRAX_FLASH_LENGTH CONFIG_ETRAX_GPIO CONFIG_ETRAX_I2C CONFIG_ETRAX_I2C_USES_PB_NOT_PB_I2C CONFIG_ETRAX_IDE CONFIG_ETRAX_IDE_CSE1_16_RESET CONFIG_ETRAX_IDE_G27_RESET CONFIG_ETRAX_IDE_PB7_RESET CONFIG_ETRAX_LED1G CONFIG_ETRAX_LED1R CONFIG_ETRAX_LED2G CONFIG_ETRAX_LED2R CONFIG_ETRAX_LED3G CONFIG_ETRAX_LED3R CONFIG_ETRAX_NO_LEDS CONFIG_ETRAX_PA_BUTTON_BITMASK CONFIG_ETRAX_PA_LEDS CONFIG_ETRAX_PB_LEDS CONFIG_ETRAX_SER0_CD_ON_PB_BIT CONFIG_ETRAX_SER0_DSR_ON_PB_BIT CONFIG_ETRAX_SER0_DTR_ON_PB_BIT CONFIG_ETRAX_SER0_DTR_RI_DSR_CD_ON_PB CONFIG_ETRAX_SER0_RI_ON_PB_BIT CONFIG_ETRAX_SER1_CD_ON_PB_BIT CONFIG_ETRAX_SER1_DSR_ON_PB_BIT CONFIG_ETRAX_SER1_DTR_ON_PB_BIT CONFIG_ETRAX_SER1_DTR_RI_DSR_CD_ON_PB CONFIG_ETRAX_SER1_RI_ON_PB_BIT CONFIG_ETRAX_SER2_CD_ON_PA_BIT CONFIG_ETRAX_SER2_DSR_ON_PA_BIT CONFIG_ETRAX_SER2_DTR_ON_PA_BIT CONFIG_ETRAX_SER2_DTR_RI_DSR_CD_ON_PA CONFIG_ETRAX_SER2_RI_ON_PA_BIT CONFIG_ETRAX_SERIAL CONFIG_ETRAX_SERIAL_PORT1 CONFIG_ETRAX_SERIAL_PORT2 CONFIG_ETRAX_SERIAL_PORT3 CONFIG_ETRAX_SYNCHRONOUS_SERIAL CONFIG_ETRAX_SYNCHRONOUS_SERIAL0_DMA CONFIG_ETRAX_SYNCHRONOUS_SERIAL1_DMA CONFIG_ETRAX_SYNCHRONOUS_SERIAL_PORT0 CONFIG_ETRAX_SYNCHRONOUS_SERIAL_PORT1 CONFIG_ETRAX_USB_HOST CONFIG_ETRAX_USB_HOST_PORT1 CONFIG_ETRAX_USB_HOST_PORT2 CONFIG_ETRAX_WATCHDOG CONFIG_FB_ATY_CT CONFIG_FB_ATY_GX CONFIG_FB_RADEON CONFIG_FB_SIS_300 CONFIG_FB_SIS_315 CONFIG_FB_STI CONFIG_FPS850L CONFIG_HD64465_PCMCIA CONFIG_HISAX_ELSA_CS CONFIG_HISAX_SEDLBAUER_CS CONFIG_IDE_DELAY CONFIG_IRQ_ALL_CPUS CONFIG_IVMS8 CONFIG_JULIETTE CONFIG_KCORE CONFIG_KERNEL_IFCONFIG CONFIG_LVM_PROC_FS CONFIG_MCYRIXIII CONFIG_MIPS_RTC CONFIG_MPENTIUMIII CONFIG_NLS_CODEPAGE_1251 CONFIG_NLS_ISO8859_13 CONFIG_NLS_KOI8_U CONFIG_PA_CHANGEABLE_BITS CONFIG_PA_CHANGEABLE_DIR CONFIG_PB_CHANGEABLE_BITS CONFIG_PB_CHANGEABLE_DIR CONFIG_PROCESS_DEBUG CONFIG_PROFILE CONFIG_PROFILE_SHIFT CONFIG_RESCUE_SER0 CONFIG_RESCUE_SER1 CONFIG_RESCUE_SER2 CONFIG_RESCUE_SER3 CONFIG_RS485 CONFIG_RS485_DISABLE_RECEIVER CONFIG_RS485_ON_PA CONFIG_RS485_ON_PA_BIT CONFIG_S390_SUPPORT CONFIG_S390_TAPE CONFIG_S390_TAPE_3480 CONFIG_S390_TAPE_3490 CONFIG_S390_TAPE_BLOCK CONFIG_S390_TAPE_CHAR CONFIG_SCC3_ENET CONFIG_SDRAM CONFIG_SM850 CONFIG_SOUND_MAESTRO3 CONFIG_SOUND_YMFPCI_LEGACY CONFIG_SPD823TS CONFIG_SVINTO_SIM CONFIG_TMSISA CONFIG_TQM823L CONFIG_TQM850L CONFIG_TQM855L CONFIG_USB_HP5300 CONFIG_USE_MDIO CONFIG_USE_SERIAL_CONSOLE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: HP Vectra XU 5/90 interrupt problems
>From: "Dunlap, Randy" <[EMAIL PROTECTED]> > > > -Original Message- > > From: John William [mailto:[EMAIL PROTECTED]] > > If PCI interrupts are shared, force them to be level > > triggered? Can shared > > PCI interrupts be edge triggered? If not, then wouldn't this > > be the correct > > solution? This isn't specific to the Vectra, but could > > possibly prevent problems on any machine with a broken BIOS? > >PCI interrupts are defined as "level sensitive" and must >be shareable. > >~Randy So PCI interrupts must always be level triggered? If so, then the kernel should never program the IO APIC to use an edge triggered interrupt on a PCI device. If that's true, then why not force the interrupt type to level triggered for all PCI devices (to work around a potentially broken MP table)? What about this solution: 1) In pci-irq.c, in pcibios_fixup_irqs(), if we are using the IO APIC, check to see if the IRQ has been set to level triggered. 2a) If YES, then do nothing different. 2b) If NO, then set the IRQ type to level triggered and write the changed configuration to the IO APIC for that interrupt. The other alternative I considered is adding a check for the presence of ELCR data to construct_default_ISA_mptable() in mpparse.c, but there doesn't seem to be an easy way to verify that there really is (or isn't) valid ELCR data. Apparently, HP chose to use the ELCR to provide IRQ information on their early SMP machines, but since the system is defined as type 5 (ISA/PCI), the kernel doesn't check for the presence of ELCR data, and the machine's MP table does not appear to have any IRQ information. But if PCI interrupts have to be level triggered, then the first alternative would seem to be a more general solution. _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: fix ethernet device initialization
Jes Sorensen wrote: > I don't like the way you declare all the code in obscure macros in > there. > > +#define DECLARE_CHG_MTU(suffix,low,high) \ > + static int suffix##_change_mtu(struct net_device *dev, int new_mtu) \ > .. > > All it does is to make the code harder to read and debug for little/no > gain. I disagree, but you probably knew that when you saw the code :) These macros are not used inside code, they declare entire functions. These functions are 100% duplicated across 2-4 protocols. Duplicated code means bugs in some portions of the code and no others, more difficult to maintain, etc. I even proved this point while developing the patch -- one of the functions was missing an EXPORT_xxx symbol. Using a standard macro automatically fixed this, a small oversight that had been in the kernel probably for over a year. -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: RTL8029 stops working after being flood pinged
[1.] One line summary of the problem:
RTL8029 based card stops receiving data after being flood pinged
[2.] Full description of the problem/report:
I tried flood pinging a host with a RTL8029. After approximately
20 packets the host stops responding to the network. The
link light in the hub is on, but sniffing on the network from the
host receives no packets.
If I exchange the RTL8029 with a RTL8139 the host survives the flood
pinging.
[3.] Keywords (i.e., modules, networking, kernel):
networking ne2k-pci
[4.] Kernel version (from /proc/version):
Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #37 SMP Sat Mar 10 03:14:07 CET
2001
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
No OOPS.
[6.] A small shell script or example program which triggers the
problem (if possible)
host2# ping -f host1 -c 50
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux tigger.tange.dk 2.4.2 #37 SMP Sat Mar 10 03:14:07 CET 2001 i686
unknown
Kernel modules 2.3.19
Gnu C 2.95.3
Gnu Make 3.79.1
Binutils 2.10.0.24
Linux C Library2.1.95
Dynamic linker ldd (GNU libc) 2.1.95
Procps 2.0.7
Mount 2.10o
Net-tools 1.57
Console-tools 0.2.3
Sh-utils 2.0
cat: /proc/modules: No such file or directory
Modules Loaded
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 6
model name : Celeron (Mendocino)
stepping: 5
cpu MHz : 534.551
cache size : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov
pat pse36 mmx fxsr
bogomips: 1064.96
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 6
model name : Celeron (Mendocino)
stepping: 5
cpu MHz : 534.551
cache size : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov
pat pse36 mmx fxsr
bogomips: 1068.23
[7.3.] Module information (from /proc/modules):
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
4000-403f : Intel Corporation 82371AB PIIX4 ACPI
5000-501f : Intel Corporation 82371AB PIIX4 ACPI
c000-c01f : Intel Corporation 82371AB PIIX4 USB
c000-c01f : usb-uhci
c400-c41f : Creative Labs SB Live! EMU1
c400-c41f : EMU10K1
c800-c807 : Creative Labs SB Live!
cc00-cc1f : Realtek Semiconductor Co., Ltd. RTL-8029(AS)
cc00-cc1f : ne2k-pci
d000-d007 : Triones Technologies, Inc. HPT366
d400-d403 : Triones Technologies, Inc. HPT366
d800-d8ff : Triones Technologies, Inc. HPT366
d800-d807 : ide1
d810-d8ff : HPT366
dc00-dc07 : Triones Technologies, Inc. HPT366 (#2)
e000-e003 : Triones Technologies, Inc. HPT366 (#2)
e400-e4ff : Triones Technologies, Inc. HPT366 (#2)
e400-e407 : ide2
e410-e4ff : HPT366
f000-f00f : Intel Corporation 82371AB PIIX4 IDE
f000-f007 : ide0
-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-2fff : System RAM
0010-00269ba8 : Kernel code
00269ba9-002dddbf : Kernel data
d000-d3ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
d400-d7ff : PCI Bus #01
d400-d4003fff : Matrox Graphics, Inc. MGA G200 AGP
d500-d57f : Matrox Graphics, Inc. MGA G200 AGP
d800-d8ff : PCI Bus #01
d800-d8ff : Matrox Graphics, Inc. MGA G200 AGP
fec0-fec00fff : reserved
fee0-fee00fff : reserved
- : reserved
[7.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
(prog-if 00
Re: Linux 2.4.2ac12 and ac13 breaks usb-visor
On Fri, Mar 09, 2001 at 09:10:32PM -0500, David Huggins-Daines wrote: > It's the one listed in arch/i386/defconfig. Of course, it's debatable > whether that actually means 'default' or not (since in fact it's more > like 'what Linus uses'), but plenty of people will see it as such. Thanks for pointing that out to me, I think it's time for a documentation patch :) greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Possible bug with poll syscall
Alex Baretta wrote:
>
> Alex Baretta wrote:
> >
> > I am using poll with the POLLIN flag to wait for connection
> > requests on a set of listening sockets in a server process.
> > Although clients attempt to connect to those sockets, poll does
> > returns zero after the expiration of the timeout.
...
There was a bug in my code. I am unable to find it, but I wrote a
minimal to case to prove my point, and actually I proved myself
wrong. Test case follows. If I ever find the time I'll try to
experiment and discover why in "the real thing" poll did not work
for me.
#include
#include
#include
#include
int main(int argc, char **argv) {
struct pollfd fds;
int res1, res2, nevents;
struct sockaddr_in sockaddr;
fds.fd = socket(PF_INET, SOCK_STREAM, 0);
fds.events = POLLIN;
sockaddr.sin_family = AF_INET;
sockaddr.sin_addr.s_addr = htonl(INADDR_ANY);
sockaddr.sin_port = htons(5);
res1 = bind(fds.fd, (struct sockaddr *)&sockaddr,
sizeof(sockaddr));
res2 = listen(fds.fd, 20);
if (fds.fd == -1 || res1 == -1 || res2 == -1) {
fprintf(stderr, "The program failed miserably.\n");
exit(1);
}
fprintf(stderr, "I'm about to suspend myself on a poll
syscall!\n");
nevents = poll(&fds, 1, -1);
fprintf(stderr, "Waking up: nevents = %d\n", nevents);
return 0;
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
compilation error in 2.4.3-pre3
Hello, I get the following compilation error: gcc -D__KERNEL__ -I/tmp2/src/linux-2.4.3.jh/include -Wall -Wstrict-prototypes -O 2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 - march=i686 -malign-functions=4 -c -o proc_misc.o proc_misc.c proc_misc.c: In function `read_profile': proc_misc.c:452: `prof_shift' undeclared (first use in this function) proc_misc.c:452: (Each undeclared identifier is reported only once proc_misc.c:452: for each function it appears in.) proc_misc.c:454: `prof_len' undeclared (first use in this function) proc_misc.c:464: `prof_buffer' undeclared (first use in this function) proc_misc.c: In function `write_profile': proc_misc.c:494: `prof_len' undeclared (first use in this function) proc_misc.c:494: `prof_buffer' undeclared (first use in this function) proc_misc.c: In function `proc_misc_init': proc_misc.c:563: `prof_shift' undeclared (first use in this function) proc_misc.c:567: `prof_len' undeclared (first use in this function) make[3]: *** [proc_misc.o] Error 1 make[3]: Leaving directory `/tmp2/src/linux-2.4.3.jh/fs/proc' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/tmp2/src/linux-2.4.3.jh/fs/proc' make[1]: *** [_subdir_proc] Error 2 make[1]: Leaving directory `/tmp2/src/linux-2.4.3.jh/fs' make: *** [_dir_fs] Error 2 I use: # gcc --version 2.95.3 (Mandrake 7.2) This variables were defined in asm/string.h but now I can only find them in asm/hw_irq.h. I have included asm/hw_irq.h and it compiles but I get a warning: make[3]: Entering directory `/tmp2/src/linux-2.4.3.jh/fs/proc' gcc -D__KERNEL__ -I/tmp2/src/linux-2.4.3.jh/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -c -o proc_misc.o proc_misc.c In file included from proc_misc.c:42: /tmp2/src/linux-2.4.3.jh/include/asm/hw_irq.h:219: warning: `struct hw_interrupt_type' declared inside parameter list /tmp2/src/linux-2.4.3.jh/include/asm/hw_irq.h:219: warning: its scope is only this definition or declaration, which is probably not what you want. rm -f proc.o Bye, Joachim P.S. Please send also an email to my private address as I am not subscribed to the list. -- Joachim Herb mailto:[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/
[PATCH] remove duplicate Configure.help entries in 2.4.2-ac18
As of 2.4.2-ac18, there are two CONFIG options which have two entries in Documentation/Configure.help. These are CONFIG_IP_NF_TARGET_TCPMSS and CONFIG_DEBUG_IOVIRT. The first of these has two identical entries, so this patch deletes the duplicate entry. The second, CONFIG_DEBUG_IOVIRT, has a second but different entry in Configure.help. I've merged one perhaps useful line from that second (and therefore ignored) entry into the first one. The new line (updated) is: "This can be very useful for porting drivers from 2.2 to 2.4." You can see the original comment near the end of the patch, where the second entry is deleted. This patch is against 2.4.2-ac18. Steven --- linux/Documentation/Configure.help.orig Sat Mar 10 17:50:58 2001 +++ linux/Documentation/Configure.help Sat Mar 10 18:05:57 2001 @@ -2045,31 +2045,6 @@ If you want to compile it as a module, say M here and read Documentation/modules.txt. If unsure, say `N'. -TCPMSS target support -CONFIG_IP_NF_TARGET_TCPMSS - This option adds a `TCPMSS' target, which allows you to alter the - MSS value of TCP SYN packets, to control the maximum size for that - connection (usually limiting it to your outgoing interface's MTU - minus 40). - - This is used to overcome criminally braindead ISPs or servers which - block ICMP Fragmentation Needed packets. The symptoms of this - problem are that everything works fine from your Linux - firewall/router, but machines behind it can never exchange large - packets: - 1) Web browsers connect, then hang with no data received. - 2) Small mail works fine, but large emails hang. - 3) ssh works fine, but scp hangs after initial handshaking. - - Workaround: activate this option and add a rule to your firewall - configuration like: - -iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ --j TCPMSS --clamp-mss-to-pmtu - - If you want to compile it as a module, say M here and read - Documentation/modules.txt. If unsure, say `N'. - LOG target support CONFIG_IP_NF_TARGET_LOG This option adds a `LOG' target, which allows you to create rules in @@ -15225,6 +15200,9 @@ If you say Y here, all the memory mapped input and output on devices will go through a check to catch access to unmapped ISA addresses, that can still be used by old drivers. + + This can be very useful for porting drivers from 2.2 to 2.4. + If you say N, I/O will be faster and kernel will be a bit smaller, but no check will be done. @@ -17885,12 +17863,6 @@ Say Y here to have the kernel do limited verification on memory allocation as well as poisoning memory on free to catch use of freed memory. - -Memory mapped I/O debugging -CONFIG_DEBUG_IOVIRT - Say Y here to get warned whenever an attempt is made to do I/O on - obviously invalid addresses such as those generated when ioremap() - calls are forgotten. Very useful for porting drivers from 2.0/2.2 Spinlock debugging CONFIG_DEBUG_SPINLOCK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.2 Lockup in SCSI Error Handler
Hello, I'm running 2.4.2 with KDB patch on an SMP system. I have an Adaptec 2940 SCSI card that my CD burner is connected to. When this happened, I was not using the CD at all. This is on a Tyan Tiger 133 motherboard (with the Via Apollo Pro 133a chipset). I'm running with "noapic" due to the Via PCI IRQ routing problem, so that I can use USB devices. I'm not very good with debuggers or hunting down kernel bugs, so I apologize in advance. Here's what I found: Stack traceback for pid 448 EBP EIP Function(args) 0xe68f1f6c 0xc011524a schedule+0x41e (0xe76021c0, 0xe68f) kernel .text 0xc010 0xc0114e2c 0xc0115460 0xe68f1f9c 0xc0107bb8 __down_interruptible+0x94 kernel .text 0xc010 0xc0107b24 0xc0107c24 0xe68f1fac 0xc0107c96 __down_failed_interruptible+0xa (0x100, 0xe694dd14, 0xe694dd6c, 0xe68f1fd8, 0x0) kernel .text 0xc010 0xc0107c8c 0xc0107c9c 0xe8f4edbf [scsi_mod].text.lock+0x1fb scsi_mod .text.lock 0xe8f4ebc4 0xe8f4ebc4 0xe8f4eee8 0xe68f1fec 0xe8f4a2bf [scsi_mod]scsi_error_handler+0x107 scsi_mod .text 0xe8f45060 0xe8f4a1b8 0xe8f4a330 0xc0107547 kernel_thread+0x23 kernel .text 0xc010 0xc0107524 0xc010755c [0]kdb> id 0xe8f4eba0 0xe8f4eba0 scan_scsis_single+0x594cmp$0x1,%dl 0xe8f4eba3 scan_scsis_single+0x597jne0xe8f4ebaf scan_scsis_single+0x5a3 0xe8f4eba5 scan_scsis_single+0x599testb $0xf,0x3(%eax) 0xe8f4eba9 scan_scsis_single+0x59dje 0xe8f4e6f5 scan_scsis_single+0xe9 0xe8f4ebaf scan_scsis_single+0x5a3mov$0x1,%eax 0xe8f4ebb4 scan_scsis_single+0x5a8lea0xff68(%ebp),%esp 0xe8f4ebba scan_scsis_single+0x5aepop%ebx 0xe8f4ebbb scan_scsis_single+0x5afpop%esi 0xe8f4ebbc scan_scsis_single+0x5b0pop%edi 0xe8f4ebbd scan_scsis_single+0x5b1mov%ebp,%esp 0xe8f4ebbf scan_scsis_single+0x5b3pop%ebp 0xe8f4ebc0 scan_scsis_single+0x5b4ret 0xe8f4ebc1 scan_scsis_single+0x5b5nop 0xe8f4ebc2 scan_scsis_single+0x5b6nop 0xe8f4ebc3 scan_scsis_single+0x5b7nop 0xe8f4ebc4 .text.lockcall 0xc0107cac __up_wakeup [0]kdb> id 0xe8f4ebb0 0xe8f4ebb0 scan_scsis_single+0x5a4add%eax,(%eax) 0xe8f4ebb2 scan_scsis_single+0x5a6add%al,(%eax) 0xe8f4ebb4 scan_scsis_single+0x5a8lea0xff68(%ebp),%esp 0xe8f4ebba scan_scsis_single+0x5aepop%ebx 0xe8f4ebbb scan_scsis_single+0x5afpop%esi 0xe8f4ebbc scan_scsis_single+0x5b0pop%edi 0xe8f4ebbd scan_scsis_single+0x5b1mov%ebp,%esp 0xe8f4ebbf scan_scsis_single+0x5b3pop%ebp 0xe8f4ebc0 scan_scsis_single+0x5b4ret 0xe8f4ebc1 scan_scsis_single+0x5b5nop 0xe8f4ebc2 scan_scsis_single+0x5b6nop 0xe8f4ebc3 scan_scsis_single+0x5b7nop 0xe8f4ebc4 .text.lockcall 0xc0107cac __up_wakeup 0xe8f4ebc9 .text.lock+0x5jmp0xe8f450ae scsi_wait_done+0x22 0xe8f4ebce .text.lock+0xacmpb $0x0,0xe8f58af4 0xe8f4ebd5 .text.lock+0x11repz nop [0]kdb> id 0xe8f4edbf 0xe8f4edbf .text.lock+0x1fbjmp0xe8f4a2bf scsi_error_handler+0x107 0xe8f4edc4 .text.lock+0x200call 0xc0107cac __up_wakeup 0xe8f4edc9 .text.lock+0x205jmp0xe8f4a320 scsi_error_handler+0x168 0xe8f4edce .text.lock+0x20acmpb $0x0,0xc027d140 0xe8f4edd5 .text.lock+0x211repz nop 0xe8f4edd7 .text.lock+0x213jle0xe8f4edce .text.lock+0x20a 0xe8f4edd9 .text.lock+0x215jmp0xe8f4a33b scsi_old_times_out+0xb 0xe8f4edde .text.lock+0x21acmpb $0x0,0xc027d140 0xe8f4ede5 .text.lock+0x221repz nop 0xe8f4ede7 .text.lock+0x223jle0xe8f4edde .text.lock+0x21a 0xe8f4ede9 .text.lock+0x225jmp0xe8f4a4d1 scsi_old_times_out+0x1a1 0xe8f4edee .text.lock+0x22acmpb $0x0,0xc027d140 0xe8f4edf5 .text.lock+0x231repz nop 0xe8f4edf7 .text.lock+0x233jle0xe8f4edee .text.lock+0x22a 0xe8f4edf9 .text.lock+0x235jmp0xe8f4aa71 scsi_old_done+0x501 0xe8f4edfe .text.lock+0x23acmpb $0x0,0xc027d140 Is this a known problem that's been fixed in the AC or test line? Is there any more information I can provide about my system? Any tips on better information to grab next time something like this happens? Thanks, pete PGP signature
Re: filesystem for initrd
Art Boulatov wrote: > I'm in the process of creating a custom "system partition" > for out Linux servers, which is actually an initial ramdisk, > coming from hd or network on boot > to load necessary drivers and perform important checks > before the real filesystems get mounted, > and I did not find any info on > what filesystems can I use > for initrd, are there any restrictions? > Mostly interested in cramfs, > due to it's compression. Any filesystem which works with a normal block device, such as a hard drive, will work with a ramdisk. Read ramdisk.txt and initrd.txt in the linux/Documentation directory, in your Linux kernel source tree. cramfs is nice but still read-only at the moment... You might be able to get away with stacking ramfs on top of that. If not, it shouldn't be hard to modify cramfs so that it allows fs modifications... just stick the updated pages in RAM until the file is unlinked or the fs is unmounted. -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
filesystem for initrd
Hi, I'm in the process of creating a custom "system partition" for out Linux servers, which is actually an initial ramdisk, coming from hd or network on boot to load necessary drivers and perform important checks before the real filesystems get mounted, and I did not find any info on what filesystems can I use for initrd, are there any restrictions? Mostly interested in cramfs, due to it's compression. Could anybody help me work this out or point to the right place for more info? Thanks a lot, Art. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: quicksort for linked list
On Sat, Mar 10, 2001 at 07:50:06PM +0100, Martin Mares wrote: > Hello! > > > Well, not really in this situation, after a simple modification. It is > > trivial to show that using "shorter interval sorted first" approach one > > can bound an amount of an extra memory, on stack or otherwise, and by a > > rather small number. > > By O(log N) which is in reality a small number :) Assuming that we sort a full range of 32-bit numbers (pointers on a 32-bit CPU, for example, are numbers of that kind but usually a range can be narrowed down quite substantially) then with a bit of a careful programming you need, I think, something like 16 extra 4-byte words or maybe even a bit less. I do not remember precisely, as I was doing this exercise a long time ago, but even if this is 32, and you need carefuly constructed example to need them all these extra cells, I still think that this is not a huge amount of memory. Especially when every element of a list you are sorting is likely quite a bit bigger. Exponents are something which grows these numbers pretty fast. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.2ac18
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org (Note that the cmsfs port to 2.4 is a work in progress) 2.4.2-ac18 o Debian has another location for db3 (Marc Volovic) o Remove duplicated flush_tlb_page export on (Elliot Lee) Alpha o Fix SB Live! build on SMP Alpha (Elliot Lee) o Fix disk corruption on qlogicisp and qlogicpti (Arjan van de Ven) o Fix reporting of >4Gig of swap (Hugh Dickins) o Fix sign issues in mpt fusion (Andrew Morton) o CMS minidisk file system (read only)(Rick Troth) 2.4 port(me) o Disable nmi watchdog by default (Andrew Morton) o Fix elsa_cs eject problems (Klaus Lichtenwalder) o Remove duplicate config entries (Steven Cole) o Fix further wrong license references(Andrzej Krzysztofowicz) o Add nmi watchdog disable for sysrq (Andrew Morton) o Experimental test for serverworks/intel AGP (me) comptability o Fix ipx reference counting for routes (Arnaldo Carvalho de Melo) 2.4.2-ac17 o Make the aic7xxx code handle multiple db3 paths (me) o Small further via updates (Vojtech Pavlik) o IDE tape updates for Onstream tape drives (Marcel Mol) o Remove some bits of module.c that cant get (Keith Owens executed Andrew Morton) o Configure.help fixups (Steven Cole) o Add Cyrix MTRR data (Dave Jones) o Fix a slight bogon in the i386 Makefile (Dave Jones) o Kill an escaped modversions.h (Keith Owens) o Further controlfb fixes (Takashi Oe) o Fix console driver oops in new locking (Andrew Morton) o Add 'broken-psr' so you can command line tell (Neale Banks) APM your BIOS is crap o Fix serial console (Dave Jones) o Fix megaraid kernel_version string (Arjan van de Ven) o Fix off by one error in cpia(Andrew Morton) o Fix lost dmfe typo fix (Torsten Duwe) o Take kernel_lock for i_truncate method in (Al Viro) vmtruncate o Fix i2c sign check bug (Andrew Morton) 2.4.2-ac16 o Uniprocessor APIC fixes for misdetect (Mikael Pettersso) o Small ymf_pci fixes/updates (Pete Zaitcev) o Fix break support on sx serial (Rogier Wolff) o Kill another dead config.in entry (Steven Cole) o Add bust spinlocks logic to S/390 (Neale Ferguson) o Fix ramdisk buffer only page bug(Philipp Rumpf) o Mark ips scsi experimental until IBM ship a (Adam Lackorzynski) proper 2.4 driver o Update lanstreamer to use module_init and more (Mike Sullivan) o Switch to the updated irda fixes(Jean Tourrilhes) o Vaio kaweth ethernet apparently has its own id (Sven Anders) o d_validate clean ups(Petr Vandrovec) o Network further fixes from DaveM and co (Dave Miller | This might fix the reported masuqerade crashes Alexey Kuznetsov Werner Almesberger) o Acenic updates (Jes Sorensen) 2.4.2-ac15 o Add CyrixIII specific kernel configuration (me) | Note there are CyrixIII problems with some distribution installers | because -m686 gcc output will not run on a model 6 cpu with no | cmov. o Fix aic Makefile for older gnu make (Keith Owens) o Assorted i2o updates/partition handling fixes (Boji Kannanthanam) o Fix dcache problems with ncpfs (Petr Vandrovec) o Update via drivers to 3.22 (Vojtech Pavlik) o Account for packet bytes on lmc driver (Ernst Lehmann) o Atyfb rearrange (Geert Uytterhoeven) o Fix sedlbauer_cs build bug add elsa_cs (Than Ngo) | elsa_cs driver by (Klaus Lichtenwalder) o Add support for the Fuji FinePix 1400Zoon (Nate) o EISA initialisation changes for 3c59x (Andrzej Krzysztofowicz) o Assorted small net protocol updates (Dave Miller) o Fix dvd physical read bug (Jens Axboe) o Fix ATM hang on SMP
RE: HP Vectra XU 5/90 interrupt problems
> -Original Message- > From: John William [mailto:[EMAIL PROTECTED]] > > I'm having a problem with kernel 2.4.2-SMP on my HP Vectra XU > 5/90. This is an old dual-pentium (Neptune chipset) machine. > ... > > OR > > If PCI interrupts are shared, force them to be level > triggered? Can shared > PCI interrupts be edge triggered? If not, then wouldn't this > be the correct > solution? This isn't specific to the Vectra, but could > possibly prevent problems on any machine with a broken BIOS? PCI interrupts are defined as "level sensitive" and must be shareable. ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ac97_codec: AD1885 id 0x41445360 changed to 0x41445460 in 2.4.2-ac patches?
Alan,
Last night I moved from an old BX/PII board to an i815e/PIII
board (an Intel D815EEA with an AD1885 and onboard LAN enabled),
and in trying to set up my AC97 audio (there's an Analog Devices
AD1885 on the board), I found that the vanilla 2.4.2 kernel has
an id match for an AD1885 with a line like
{0x41445360, "Analog Devices AD1885" , enable_eapd},
in drivers/sound/ac97_codec.c, but in the -ac patches (I've
tried -ac16 and -ac17) that id has been changed to 0x41445460
which causes the ac97_codec module to not recognize the hardware
for the -ac series. Here's the snippet from patch-2.4.2-ac17 which
(the diff is on drivers/sound/ac97_codec.c) shows the change:
-8<-
220108 } ac97_codec_ids[] = {
220109 - {0x414B4D00, "Asahi Kasei AK4540 rev 0", NULL},
220110 - {0x414B4D01, "Asahi Kasei AK4540 rev 1", NULL},
220111 - {0x41445340, "Analog Devices AD1881" , NULL},
220112 - {0x41445360, "Analog Devices AD1885" , enable_eapd},
.
.
.
220124 + {0x41445303, "Analog Devices AD1819", NULL},
220125 + {0x41445340, "Analog Devices AD1881", NULL},
220126 + {0x41445348, "Analog Devices AD1881A", NULL},
220127 + {0x41445460, "Analog Devices AD1885", enable_eapd},
-8<-
So, in 2.4.2-ac1[67], a line like
kernel: ac97_codec: AC97 Audio codec, id: 0x4144:0x5360 (Unknown)
shows up in '/var/log/messages', while with that ID in ac97_codec.c
changed back, I get this:
kernel: ac97_codec: AC97 Audio codec, id: 0x4144:0x5360 (Analog Devices AD1885)
and then sound works after loading i810_audio.
My question is, why did the ID change in ac97_codec.c? Am I
supposed to add some sort of switch to modules.conf to tell it
what chip I've got? Is it just a typo (the AD1881 ID didn't
change)?
Thanks,
-jesse
Jesse Wyant - [EMAIL PROTECTED]
I will not forget you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VMware 2.0.3 & Kernel 2.4.2-ac17
Jeff Lightfoot wrote: > Here is a patch for vmware that was on the vmware newsgroups. > (Hopefully wordwrap didn't screw this up) Thanks, after applying by hand, it worked. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NFS times out with 2.4.2 as client
I built 2.4.2 to experiment with it. So far, I can't get it to mount an nfs share without timing out. The nfs server, in this case, is running 2.2.17. There are no problems mounting the share when I revert to the old kernel, 2.2.16, on the client machine. Other than that there's nothing special about the setup. The connection occurs across the LAN. Apparently although the server recognizes the client packets, its answers are not understood by the client, which tries different ports. Eventually, the client reports a timeout, but in fact the share is successfully mounted. I've tried a number of solutions, including a newer version of mount, adding nolock to the options line, and also vers=2. Ver3 is not selected in the 2.4.2 kernel, indidentally. At first I suspected the firewall, but the same results happen when the fw is down. The only entries in the kernel log say, portmap: server not responding. During this time the terminal on which the commands are entered won't respond to input (you can open up another connection remotely). Here's a typical entry from tcpdump, from the server's point of view. 192.168.1.1 is the client, 192.168.1.10 is the server. tcpdump: listening on eth0 11:32:24.958338 localhost.localdomain.631 > 192.168.1.255.631: udp 124 11:32:55.958333 localhost.localdomain.631 > 192.168.1.255.631: udp 124 11:32:56.736047 arp who-has localhost.localdomain tell 192.168.1.1 11:32:56.736083 arp reply localhost.localdomain is-at 0:0:e8:35:77:ae 11:32:56.736615 192.168.1.1.745 > localhost.localdomain.sunrpc: S 1160224917:1160224917(0) win 5840 (DF) 11:32:56.736772 localhost.localdomain.sunrpc > 192.168.1.1.745: S 980802949:980802949(0) ack 1160224918 win 32120 (DF) 11:32:56.737386 192.168.1.1.745 > localhost.localdomain.sunrpc: . ack 1 win 5840 (DF) 11:32:56.738109 192.168.1.1.745 > localhost.localdomain.sunrpc: P 1:45(44) ack 1 win 5840 (DF) 11:32:56.738152 localhost.localdomain.sunrpc > 192.168.1.1.745: . ack 45 win 32120 (DF) 11:32:56.738412 localhost.localdomain.sunrpc > 192.168.1.1.745: P 1:293(292) ack 45 win 32120 (DF) 11:32:56.738692 localhost.localdomain.1051 > 151.164.1.8.domain: 52408+ (42) 11:32:56.739497 192.168.1.1.745 > localhost.localdomain.sunrpc: . ack 293 win 6432 (DF) 11:32:56.740010 192.168.1.1.745 > localhost.localdomain.sunrpc: F 45:45(0) ack 293 win 6432 (DF) 11:32:56.740041 localhost.localdomain.sunrpc > 192.168.1.1.745: . ack 46 win 32120 (DF) 11:32:56.740137 localhost.localdomain.sunrpc > 192.168.1.1.745: F 293:293(0) ack 46 win 32120 (DF) 11:32:56.740779 192.168.1.1.745 > localhost.localdomain.sunrpc: . ack 294 win 6432 (DF) 11:32:56.741604 192.168.1.1.746 > localhost.localdomain.1026: udp 144 (DF) 11:32:56.742060 localhost.localdomain.1026 > 192.168.1.1.746: udp 60 11:32:56.743109 192.168.1.1.748 > localhost.localdomain.sunrpc: udp 56 (DF) 11:32:56.743255 localhost.localdomain.sunrpc > 192.168.1.1.748: udp 28 11:32:56.745189 192.168.1.1.2121638 > localhost.localdomain.nfs: 152 getattr [|nfs] (DF) 11:32:56.745254 localhost.localdomain.nfs > 192.168.1.1.2121638: reply ok 96 getattr [|nfs]11:32:56.746302 192.168.1.1.18898854 > localhost.localdomain.nfs: 152 statfs [|nfs] (DF) 11:32:56.746375 localhost.localdomain.nfs > 192.168.1.1.18898854: reply ok 48 statfs [|nfs]11:33:01.748311 localhost.localdomain.1051 > 151.164.1.7.domain: 52408+ (42) 11:33:51.778238 arp who-has 192.168.1.1 tell localhost.localdomain 11:33:51.778738 arp reply 192.168.1.1 is-at 0:0:e8:35:7e:51 11:33:55.078917 0:20:78:d:3d:ce > 3:0:0:0:0:1 sap f0 ui/C len=169 2c00 ffef 0800 0102 5f5f 4d53 4252 4f57 5345 5f5f 0201 5241 4242 4954 2020 2020 2020 2020 2000 ff53 4d42 2500 00 The rest is more of the same, or other traffic. Any one have similar problems? I've tried recompiling 2.4.2, thinking I might have missed something. No change. Perplexed. -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: [PATCH]: allow notsc option for buggy cpus
On Sat, Mar 10, 2001 at 01:19:03AM +, Alan Cox wrote: > > My IBM Thinkpad 600E changes between 100MHz and 400MHz depending if the > > power is on. This means gettimeofday goes backwards if you boot with the > Intel speedstep CPU. > > > Even so, we should really catch these cpus at run time. > Intel are being remarkably reluctant on the documentation front. We have > the AMD speed change docs, but the intel ones (chipset not cpu based > primarily) don't seem to be publically available. In fact the 815M manual > looks like someone quite pointedly went through and removed the relevant > material before publication Isn't that one of the things that the ACPI is for ? Aren't we supposed to use ACPI for this ? /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: allow notsc option for buggy cpus
> > Intel are being remarkably reluctant on the documentation front. We have > > the AMD speed change docs, but the intel ones (chipset not cpu based > > primarily) don't seem to be publically available. In fact the 815M manual > > looks like someone quite pointedly went through and removed the relevant > > material before publication > > Isn't that one of the things that the ACPI is for ? > Aren't we supposed to use ACPI for this ? If you want to trust a large in kernel interpreter of binary only interpreter code from a BIOS vendor be my guest. Im also not sure ACPI will give us the notifications we need, even in the cases where it actually works. 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: Kernel 2.4.1 on RHL 6.2
According to Alan Cox: > > Note! You only have to have those symlinks on broken systems such > > as Redhat. > > < 7.0. > 7.0 or higher keeps the glibc includes out of /usr/src I stand corrected. Thanks. Mike. -- Go not unto the Usenet for advice, for you will be told both yea and nay (and quite a few things that just have nothing at all to do with the question). -- seen in a .sig somewhere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VMware 2.0.3 & Kernel 2.4.2-ac17
Alan Cox wrote: >> I have traced this back to 2.4.2-ac4 by looking for where this function >> was removed. > >> yes, technically this probably is OT, and properly belong on the VMware >> list, but I can't access their nntp server. > > > Right so if I cant access microsofts mailing lists I should post my windows > problems here ? I dont think your logic works that way. this is lk related, at least if you read the bottom part of my message. It is part curiousity as to what this func did, how it could be replaced if I felt really motivated (I've been feeling that way lately). > > Also if you had checked the list archive its already been answered when the > last off topic poster asked.. > I checked the list archive boudicca.tux.org, used the search and gave it 'skb_datarefp', and it returned something unrelated to VMware, and 5 weeks ago at that. No followup to the post, no other info. So I posted this q to the lk list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.1 on RHL 6.2
> He probably removed the original kernel-devel package, > which contained the links above, so they would have to > be remade. Linking them to /usr/src and thus people linking them to current kernel sources while basically harmless is indeed not the preferred approach. So he's right that older RH should have put the headers for the kernel that match glibc into /usr/include directly - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.1 on RHL 6.2
> >asm -> /usr/src/linux/include/asm-i386/ > >linux -> /usr/src/linux/include/linux/ > > Note! You only have to have those symlinks on broken systems such > as Redhat. < 7.0. On RH 6.x you should have a set of 2.2 header includes at /usr/src/linux as required by the dependancies RPM uses. (kernel-headers package). 7.0 or higher keeps the glibc includes out of /usr/src - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VMware 2.0.3 & Kernel 2.4.2-ac17
> I have traced this back to 2.4.2-ac4 by looking for where this function > was removed. > yes, technically this probably is OT, and properly belong on the VMware > list, but I can't access their nntp server. Right so if I cant access microsofts mailing lists I should post my windows problems here ? I dont think your logic works that way. Also if you had checked the list archive its already been answered when the last off topic poster asked.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VMware 2.0.3 & Kernel 2.4.2-ac17
While compiling the vmnet module, there is a warning make: Entering directory `/tmp/vmware-config2/vmnet-only' bridge.c: In function `VNetBridgeReceiveFromDev': bridge.c:788: warning: implicit declaration of function `skb_datarefp' and while inserting the module /tmp/vmware-config2/vmnet.o: unresolved symbol skb_datarefp I have traced this back to 2.4.2-ac4 by looking for where this function was removed. yes, technically this probably is OT, and properly belong on the VMware list, but I can't access their nntp server. basically, why was this function removed, what did it do, what can be done to make VMware run again? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.1 on RHL 6.2
Miquel van Smoorenburg wrote:
> Note! You only have to have those symlinks on broken systems such
> as Redhat.
This is silly, Red Hat works fine for a great many people.
He probably removed the original kernel-devel package,
which contained the links above, so they would have to
be remade.
> Sane systems such as Debian have a copy of the kernel header files
> that the C library was compiled against in /usr/include/{linux,asm}
I'm glad you admit that Red Hat is every bit as sane as
debian, since the current shipping version does indeed
have the sort of /usr/include/linux hierarchy you have just
described.
jjs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: quicksort for linked list
[EMAIL PROTECTED] (Rogier Wolff) writes: > Quicksort however is an algorithm that is recursive. This means that > it can use unbounded amounts of stack -> This is not for the kernel. The implementation of Quicksort for arrays demands a recursive implementation, but for doubly-linked lists there is a trick that leads to an iterative implementation. You can implement Quicksort recursively for singly linked lists, so in a doubly-linked list you have a spare link in each node while you are doing the sort. You can hide the stack in those links, so the implementation doesn't need to be explicitly recursive. At the end of the sort, the "next" links are correct, so you have to go through and fix up the "prev" links. > Quicksort however is an algorithm that is good for large numbers of > elements to be sorted: the overhead of a small set of items to sort is > very large. Is the "normal" case indeed "large sets"? Good implementations of Quicksort actually give up on Quicksort when the list is short, and use an algorithm that is faster for that case (measurements are required to find out where the boundary between a short list and a long list lies). If the full list to be sorted is short, Quicksort will never be involved. If that happens to be the common case, then fine. > Quicksort has a very bad "worst case": quadratic sort-time. Are you > sure this won't happen? Introsort avoids this by modifying quicksort to resort to a mergesort when the recursion gets too deep. For modern machines, I'm not sure that quicksort on a linked list is typically much cheaper than mergesort on a linked list. The majority of the potential cost is likely to be in the pointer chasing involved in bringing the lists into cache, and that will be the same for both. Once the list is in cache, how much pointer fiddling you do isn't so important. For lists that don't fit into cache, the advantages of mergesort should become even greater if the literature on tape and disk sorts applies (though multiway merges rather than simple binary merges would be needed to minimize the impact of memory latency). Given this, mergesort might be generally preferable to quicksort for linked lists. But I haven't investigated this idea thoroughly. (The trick described above for avoiding an explicit stack also works for mergesort.) > Isn't it easier to do "insertion sort": Keep the lists sorted, and > insert the item at the right place when you get the new item. Easier? Yes. Slower? Yes. Does its being slow matter? Depends on the context. David Wragg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.1 on RHL 6.2
"Stephen M. Williams" wrote: > > Wow, I had no idea. I was following advice I received a long time ago > from a mailing list. If I remove those symlinks how do I go about > compiling the kernel without receiving the same errors as Srinath? Note that he said distributions such as RedHat (pre 7.0 .. I think 7.0 does it correctly). On other distros those headers are/should be included with the glibc devel stuff. You could probably copy those dirs into place on the broken distros without problems. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.1 on RHL 6.2
Wow, I had no idea. I was following advice I received a long time ago
from a mailing list. If I remove those symlinks how do I go about
compiling the kernel without receiving the same errors as Srinath?
Thanks for the correction,
Steve
On 10 Mar 2001 18:28:09 +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Stephen "M." Williams <[EMAIL PROTECTED]> wrote:
> >Make sure you have the following symlinks in your /usr/include
> >directory, assuming you're on an x86 machine:
> >
> >asm -> /usr/src/linux/include/asm-i386/
> >linux -> /usr/src/linux/include/linux/
>
> Note! You only have to have those symlinks on broken systems such
> as Redhat.
>
> Sane systems such as Debian have a copy of the kernel header files
> that the C library was compiled against in /usr/include/{linux,asm}
> instead of symlinks to the kernel source. Do not play the symlink
> trick on those systems.
>
> Before this turns into a flamewar: this has been discussed 20 or
> so times before, and both Linus and the glibc developers agree
> that you a distribution should do the latter. The headers you use
> to compile userland binaries should be the same as the C library
> was compiled against.
>
> If you need to compile a standalone module use -I/usr/src/linux/include
>
> Mike.
> --
> Go not unto the Usenet for advice, for you will be told both yea and nay (and
> quite a few things that just have nothing at all to do with the question).
> -- seen in a .sig somewhere
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: quicksort for linked list
Hello! > Well, not really in this situation, after a simple modification. It is > trivial to show that using "shorter interval sorted first" approach one > can bound an amount of an extra memory, on stack or otherwise, and by a > rather small number. By O(log N) which is in reality a small number :) Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Dijkstra probably hates me." -- /usr/src/linux/kernel/sched.c - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.1 on RHL 6.2
In article <[EMAIL PROTECTED]>,
Stephen "M." Williams <[EMAIL PROTECTED]> wrote:
>Make sure you have the following symlinks in your /usr/include
>directory, assuming you're on an x86 machine:
>
>asm -> /usr/src/linux/include/asm-i386/
>linux -> /usr/src/linux/include/linux/
Note! You only have to have those symlinks on broken systems such
as Redhat.
Sane systems such as Debian have a copy of the kernel header files
that the C library was compiled against in /usr/include/{linux,asm}
instead of symlinks to the kernel source. Do not play the symlink
trick on those systems.
Before this turns into a flamewar: this has been discussed 20 or
so times before, and both Linus and the glibc developers agree
that you a distribution should do the latter. The headers you use
to compile userland binaries should be the same as the C library
was compiled against.
If you need to compile a standalone module use -I/usr/src/linux/include
Mike.
--
Go not unto the Usenet for advice, for you will be told both yea and nay (and
quite a few things that just have nothing at all to do with the question).
-- seen in a .sig somewhere
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.4.1 on RHL 6.2
Make sure you have the following symlinks in your /usr/include directory, assuming you're on an x86 machine: asm -> /usr/src/linux/include/asm-i386/ linux -> /usr/src/linux/include/linux/ If you're using a different archetecture, check the /usr/src/linux/include/ directory and make the link with that directory. Steve On 10 Mar 2001 20:16:34 +0530, Srinath Ravinathan wrote: > Hi, > I'm trying to compile kernel 2.4.1 on RedHat 6.2 (zoot). After the make xconfig >and make dep when I give make bzlilo I get the following error message > > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o > scripts/split-include > scripts/split-include.c > In file included from /usr/include/errno.h:36, > from scripts/split-include.c:26: > /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory > make: *** [scripts/split-include] Error 1 > > What should I do? > Yours , > Srinath.R > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: aic7xxx of 2.4.2: 'cdrecord -scanbus' complains about DVD
Harald Dunkel wrote: > When I run 'cdrecord -scanbus', then cdrecord complains about my > DVD: > > # cdrecord -scanbus > Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling > Linux sg driver version: 3.1.17 > Using libscg version 'schily-0.1' > scsibus0: > 0,0,0 0) * > 0,1,0 1) * > cdrecord: Warning: controller returns wrong size for CD capabilities page. > 0,2,0 2) 'PIONEER ' 'DVD-ROM DVD-303 ' '1.09' Removable CD-ROM > 0,3,0 3) * > 0,4,0 4) 'PIONEER ' 'CD-ROM DR-U16S ' '1.01' Removable CD-ROM > 0,5,0 5) * > > Is this warning correct? Or is this a problem of cdrecord? This is noise coming out of cdrecord and not a aic7xxx, sg or linux issue. I believe Joerg Schilling is pointing out that the device in question is at variance with some standard or convention. The subject has been raised on the cdwrite list. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] remove second identical Configure.help entry for six CONFIGs
As of 2.4.2-ac17, there are 8 CONFIG parameters which have two entries in Configure.help. Of these eight, six have identical Configure.help text. The following patch removes the second identical instance of those six. If this patch is accepted, a patch to remove the obsolete version of the other two (namely CONFIG_DEBUG_IOVIRT and CONFIG_IP_NF_TARGET_TCPMSS) will be posted here. Here is the patch, against 2.4.2-ac17. Steven --- linux/Documentation/Configure.help.orig Sat Mar 10 09:35:19 2001 +++ linux/Documentation/Configure.help Sat Mar 10 09:45:50 2001 @@ -2070,15 +2070,6 @@ If you want to compile it as a module, say M here and read Documentation/modules.txt. If unsure, say `N'. -tcpmss match support -CONFIG_IP_NF_MATCH_TCPMSS - This option adds a `tcpmss' match, which allows you to examine the - MSS value of TCP SYN packets, which control the maximum packet size - for that connection. - - If you want to compile it as a module, say M here and read - Documentation/modules.txt. If unsure, say `N'. - LOG target support CONFIG_IP_NF_TARGET_LOG This option adds a `LOG' target, which allows you to create rules in @@ -17190,27 +17181,6 @@ SA-1100 based Victor Digital Talking Book Reader. See http://www.visuaide.com/pagevictor.en.html for information on this system. - -Support ARM610 processor -CONFIG_CPU_ARM6 - Say Y here if you wish to include support for the ARM610 processor. - -Support ARM710 processor -CONFIG_CPU_ARM7 - Say Y here if you wish to include support for the ARM710 processor. - -Support StrongARM(R) SA-110 processor -CONFIG_CPU_SA110 - Say Y here if you wish to include support for the Intel(R) - StrongARM(R) SA-110 processor. - -Support ARM720 processor -CONFIG_CPU_ARM720 - Say Y here if you wish to include support for the ARM720 processor. - -Support ARM920 -CONFIG_CPU_ARM920 - Say Y here if you wish to include support for the ARM920 processor. Support ARM610 processor CONFIG_CPU_ARM6 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.2 + aic7xxx still broken
On Wed, Feb 28, 2001 at 02:07:30PM +0100, Igor Mozetic <[EMAIL PROTECTED]> wrote: > 2.4.2 + stock aic7xxx: > -- > ... > SCSI host 0 channel 0 reset (pid 0) timed out - trying harder interestingly, I have exactly the same problems when booting my smp kernel with either maxcpus=1, nosmp or the second cpu removed but NOT when the kernel boots with two cpus (it works *perfectly*) Unless macpus=! switches off apic (it doens't) this doesn't look like a IRAQ problem, as the bios has no idea of the maxcpus=! option. One thing that puzzles me is why the new driver looks for db_185.h in /usr/include/db, which seems to be a rather nonstandard position for that header (none my my slackware or home-grown boxes have that directory, all of them have the db_185.h file in /usr/include, which is the standard location I'd think since glibc-2.1 installed it there). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] aicasm db3 fiasco
Thus spake Chmouel Boudjnah ([EMAIL PROTECTED]): > FAVRE Gregoire <[EMAIL PROTECTED]> writes: > > > thanks for your answer, I cannot apply your patch, don't know why, but > > readind it I think it won't change anything for me: I have db3 (I have a > > Mandrake...). > > on which version ? it works fine for me. Mandrake Cooker, but if you read the mail I send afterthat, I explained that my problem what that I was having both db3 and BerkeleyDB, removing the last one solved the problem ;-) Thanks, Greg http://ulima.unil.ch/greg ICQ:16624071 mailto:[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: sys_sched_yield fast path
Davide Libenzi <[EMAIL PROTECTED]> writes: > Probably the rate at which is called sys_sched_yield() is not so high to let > the performance improvement to be measurable. LinuxThreads mutexes call sched_yield() when a lock is locked, so when you have a multithreaded program with some lock contention it'll be called a lot. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: quicksort for linked list
Oliver Xymoron <[EMAIL PROTECTED]> writes: > On Fri, 9 Mar 2001, Rogier Wolff wrote: > > > Quicksort however is an algorithm that is recursive. This means that > > it can use unbounded amounts of stack -> This is not for the kernel. > > It is of course bounded by the input size, but yes, it can use O(n) > additional memory in the worst case. There's no particular reason this > memory has to be on the stack - it's just convenient. You only need O(log n) additional memory if you sort the shortest sublist before the longest one (and turn the second recursive call into a loop). As log n is certainly less that 64, one can even consider that Quicksort only uses a bounded amount of memory. -- Jerome - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Possible bug with poll syscall
Alex Baretta wrote: > > I am using poll with the POLLIN flag to wait for connection > requests on a set of listening sockets in a server process. > Although clients attempt to connect to those sockets, poll does > returns zero after the expiration of the timeout. The very same thing happens if I use select. It seems highly unlikely that this should be the specified behavior of poll and select alike. Is one now forced to used threads to manage multiple ports? Greetings, Alex Baretta - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
aic7xxx of 2.4.2: 'cdrecord -scanbus' complains about DVD
Hi folks, When I run 'cdrecord -scanbus', then cdrecord complains about my DVD: # cdrecord -scanbus Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling Linux sg driver version: 3.1.17 Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) * 0,1,0 1) * cdrecord: Warning: controller returns wrong size for CD capabilities page. 0,2,0 2) 'PIONEER ' 'DVD-ROM DVD-303 ' '1.09' Removable CD-ROM 0,3,0 3) * 0,4,0 4) 'PIONEER ' 'CD-ROM DR-U16S ' '1.01' Removable CD-ROM 0,5,0 5) * [snip] Is this warning correct? Or is this a problem of cdrecord? Regards Harri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: static scheduling - SCHED_IDLE?
Hi! > > did "these" apply only to the tasks, that actually hold a lock? > > if not, then i don't like this idea, as it gives the processes > > time for the only reason, that it _might_ hold a lock. this basically > > undermines the idea of static classes. in this case, we could actually > > just make the "nice" scale incredibly large and possibly nonlinear, > > as mark suggested. > > would it be possible to subqueue tasks that are holding a lock so that > they get some guaranteed amount of cpu and just leave other to be executed > when processor really idle? There was implementation which promoted SCHED_IDLE task to normal priority whenever it entered syscall. I liked it. 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/
Re: Linux kernel - and regular sync'ing?
Hi! > > at irregular intervals of 10-30 seconds, most likely calls to sync, so > > that the disk never gets to sleep for long. I've followed advice in the > > various HOWTO's, e.g. modifying the line "ud::once:/sbin/update" in > > /etc/inittab to only sync once an hour, to no avail. Watching "top", it > > Thats actually I think poor advice - it wont help and its asking to > lose data Get noflushd. (It is _also_ asking for data loose, if you write and disk is spinned down, it will *not* bother spinning it up; you can leave atimes on.) 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/
Re: Ramdisk (and other) problems with 2.4.2
Hi! > Script started on Wed Mar 7 12:22:20 2001 > # mke2fs -Fq /dev/ram0 1440 > mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 > # mount /dev/ram0 /mnt > # ls -la /mnt > total 0 > # umount /mnt > # exit > exit No "." and ".."? something is definitely wrong here! -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] aicasm db3 fiasco
FAVRE Gregoire <[EMAIL PROTECTED]> writes: > thanks for your answer, I cannot apply your patch, don't know why, but > readind it I think it won't change anything for me: I have db3 (I have a > Mandrake...). on which version ? it works fine for me. -- MandrakeSoft Inc http://www.chmouel.org --Chmouel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.4.1 on RHL 6.2
Hi, I'm trying to compile kernel 2.4.1 on RedHat 6.2 (zoot). After the make xconfig and make dep when I give make bzlilo I get the following error message gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/split-include scripts/split-include.c In file included from /usr/include/errno.h:36, from scripts/split-include.c:26: /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory make: *** [scripts/split-include] Error 1 What should I do? Yours , Srinath.R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: static scheduling - SCHED_IDLE?
On Fri, 9 Mar 2001, Jamie Lokier wrote: > Rik van Riel wrote: > > > Just raise the priority whenever the task's in kernel mode. Problem > > > solved. > > > > Remember that a task schedules itself out at the timer interrupt, > > in kernel/sched.c::schedule() ... which is kernel mode ;) > > Even nicer. On x86 change this: > > reschedule: > call SYMBOL_NAME(schedule)# test > jmp ret_from_sys_call > > to this: > > reschedule: > orl $PF_HONOUR_LOW_PRIORITY,flags(%ebx) > call SYMBOL_NAME(schedule)# test > andl $~PF_HONOUR_LOW_PRIORITY,flags(%ebx) > jmp ret_from_sys_call Wonderful ! I think we'll want to use this, since we can use it for: 1. SCHED_IDLE 2. load control, when the VM starts thrashing we can just suspend a few processes to make sure the system as a whole won't thrash to death 3. ... ? regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Possible bug with poll syscall
I am using poll with the POLLIN flag to wait for connection requests on a set of listening sockets in a server process. Although clients attempt to connect to those sockets, poll does returns zero after the expiration of the timeout. I believe this might be a bug. As far as I understand poll should be woken up by connection requests and should signal them with a POLLIN. But, then again, I might have misunderstood the specification. Would anyone please shed some light on this issue? Thank you very much. Alex Baretta - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Problem at Kernel Configuring!!!!]
Trying to build an Athlon+SMP kernel ? -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.2-ac15 #1 SMP Fri Mar 9 01:46:56 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Hashing and directories
[EMAIL PROTECTED] (Bill Crawford) wrote on 22.02.01 in <[EMAIL PROTECTED]>: > A particular reason for this, apart from filesystem efficiency, > is to make it easier for people to find things, as it is usually > easier to spot what you want amongst a hundred things than among > a thousand or ten thousand. > > A couple of practical examples from work here at Netcom UK (now > Ebone :), would be say DNS zone files or user authentication data. > We use Solaris and NFS a lot, too, so large directories are a bad > thing in general for us, so we tend to subdivide things using a > very simple scheme: taking the first letter and then sometimes > the second letter or a pair of letters from the filename. This > actually works extremely well in practice, and as mentioned above > provides some positive side-effects. So the practical difference between finding a file in a hierarchy if you already know the first N characters (because you need them to find the subdirectory it's in), and finding the same file in a flat directory still knowing the first N characters, is ... well, maybe tab completion is a tad slower. Sorry, but I can't see the human angle. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: a bug report for 2.4.2 kernel
> ude/linux/modversions.h -c -o iriap.o iriap.c > iriap.c: In function `iriap_getvaluebyclass_request_R87307dbc': > iriap.c:425: Internal error: Segmentation fault. > Please submit a full bug report. > See http://bugzilla.redhat.com/bugzilla/> for instructions. What version of gcc are you using - 2.96-54 ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: allow notsc option for buggy cpus
> The 600E's CPU doesn't actually use SpeedStep (it's only a 400MHz > Mobile Pentium2, SpeedStep made its debut with the 600MHz Mobile > Pentium3), but rather some kind of external speed throttling... which > accomplishes basically the same thing, and makes one wonder why Intel > had to go and trademark the idea of incorporating it into the CPU. Its external on the 'speedstep' mostly. Take a look at what little docs there are and you can see the mobile PIII chipset does it > I think this behaviour can be controlled with tpctl for the Thinkpads > and possibly with the Toshiba utils on Toshibas... If tpctl can do it and we know how it does it then that may be sufficient since the kernel init code can use DMI to find the 600E, tpctl copied code to go to high speed, bogomip it and then drop back. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Fwd: Problem at Kernel Configuring!!!!]
Hi, I am sending an output the last part kernel configuring. I have read and applied "Changes" which went successful. In configuring kernel, I did make xconfig, make dep, and make clean which was successful. But when I did a "make bzImage" that when I ran into problems. "Make bzImage" stop with an error. I am using Athlon 700mg/hz, 15g HD. I am running kernel 2.2.16 and distributor is Redhat. Could this be a bug in the new 2.4.2? My email address is [EMAIL PROTECTED] Thanks, Jonathan Ellison gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon-c -o init/main.o init/main.c In file included from /usr/src/linux/include/linux/irq.h:58, from /usr/src/linux/include/asm/hardirq.h:7, from /usr/src/linux/include/linux/interrupt.h:46, from /usr/src/linux/include/asm/string.h:297, from /usr/src/linux/include/linux/string.h:22, from /usr/src/linux/include/linux/fs.h:24, from /usr/src/linux/include/linux/capability.h:18, from /usr/src/linux/include/linux/binfmts.h:6, from /usr/src/linux/include/linux/sched.h:10, from /usr/src/linux/include/linux/mm.h:5, from /usr/src/linux/include/linux/slab.h:15, from /usr/src/linux/include/linux/proc_fs.h:6, from init/main.c:16: /usr/src/linux/include/asm/hw_irq.h: In function `x86_do_profile': /usr/src/linux/include/asm/hw_irq.h:198: `current' undeclared (first use in this function) /usr/src/linux/include/asm/hw_irq.h:198: (Each undeclared identifier is reported only once /usr/src/linux/include/asm/hw_irq.h:198: for each function it appears in.) In file included from /usr/src/linux/include/asm/string.h:297, from /usr/src/linux/include/linux/string.h:22, from /usr/src/linux/include/linux/fs.h:24, from /usr/src/linux/include/linux/capability.h:18, from /usr/src/linux/include/linux/binfmts.h:6, from /usr/src/linux/include/linux/sched.h:10, from /usr/src/linux/include/linux/mm.h:5, from /usr/src/linux/include/linux/slab.h:15, from /usr/src/linux/include/linux/proc_fs.h:6, from init/main.c:16: /usr/src/linux/include/linux/interrupt.h: In function `raise_softirq': /usr/src/linux/include/linux/interrupt.h:89: `current' undeclared (first use in this function) /usr/src/linux/include/linux/interrupt.h: In function `tasklet_schedule': /usr/src/linux/include/linux/interrupt.h:160: `current' undeclared (first use in this function) /usr/src/linux/include/linux/interrupt.h: In function `tasklet_hi_schedule': /usr/src/linux/include/linux/interrupt.h:174: `current' undeclared (first use in this function) In file included from /usr/src/linux/include/linux/string.h:22, from /usr/src/linux/include/linux/fs.h:24, from /usr/src/linux/include/linux/capability.h:18, from /usr/src/linux/include/linux/binfmts.h:6, from /usr/src/linux/include/linux/sched.h:10, from /usr/src/linux/include/linux/mm.h:5, from /usr/src/linux/include/linux/slab.h:15, from /usr/src/linux/include/linux/proc_fs.h:6, from init/main.c:16: /usr/src/linux/include/asm/string.h: In function `__constant_memcpy3d': /usr/src/linux/include/asm/string.h:305: `current' undeclared (first use in this function) /usr/src/linux/include/asm/string.h: In function `__memcpy3d': /usr/src/linux/include/asm/string.h:312: `current' undeclared (first use in this function) In file included from /usr/src/linux/include/linux/raid/md.h:51, from init/main.c:25: /usr/src/linux/include/linux/raid/md_k.h: In function `pers_to_level': /usr/src/linux/include/linux/raid/md_k.h:39: warning: control reaches end of non-void function make: *** [init/main.o] Error 1 gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon-c -o init/main.o init/main.c In file included from /usr/src/linux/include/linux/irq.h:58, from /usr/src/linux/include/asm/hardirq.h:7, from /usr/src/linux/include/linux/interrupt.h:46, from /usr/src/linux/include/asm/string.h:297, from /usr/src/linux/include/linux/string.h:22, from /usr/src/linux/include/linux/fs.h:24, from /usr/src/linux/include/linux/capability.h:18, from /usr/src/linux/include/linux/binfmts.h:6, from /usr/src/linux/include/linux/sched.h:10, from /usr/src/linux/include/linux/mm.h:5, from /usr/src/linux/include/linux/slab.h
Re: linux-2.4.2-ac1[67] aicam compil error
Thus spake FAVRE Gregoire ([EMAIL PROTECTED]): > Sorry if that has already been posted, I read the m-l via newsgroups. > When I try to compile, I got: > `/usr/src/linux-2.4.2-ac17/drivers/scsi/aic7xxx/aicasm' > kgcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c > aicasm_symbol.c -o aicasm > aicasm/aicasm_gram.y:45: ../queue.h: No such file or directory > ... > aicasm/aicasm_scan.l:51: y.tab.h: No such file or directory > make[5]: *** [aicasm] Error 1 > ... > Exit 2 Hum... I have done a rpm -qa|grep -i db and found that I still have BerkeleyDB-2.7.7-5mdk BerkeleyDB-devel-2.7.7-5mdk and also db3-3.1.14-2mdk and db3-devel-3.1.14-2mdk, so I did a rpm -e BerkeleyDB-2.7.7-5mdk BerkeleyDB-devel-2.7.7-5mdk and compiled 2.4.2-ac17 with no problem at all ;-) Sorry for the post, Greg http://ulima.unil.ch/greg ICQ:16624071 mailto:[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: nanosleep question
Michael Reinelt wrote: > > george anzinger wrote: > > > > Michael Reinelt wrote: > > > > > > At the moment I implemented by own delay loop using a small assembler > > > loop similar to the one used in the kernel. This has two disadvantages: > > > assembler isn't that portable, and the loop has to be calibrated. > > > > Why not use C? As long as you calibrate it, it should do just fine. > Because the compiler might optimize it away. Not if you use volatile on the data type. > > > On > > the other hand, since you are looping anyway, why not loop on a system > > time of day call and have the loop exit when you have the required time > > in hand. These calls have microsecond resolution. > I'm afraid they don't (at least with kernel 2.0, I didn't try this with > 2.4). Gosh, I started with 2.2.14 and it does full microsecond resolution. They have microsecond resolution, but increment only every 1/HZ. > > Someone gave me a hint to loop on rdtsc. I will look into this. This ticks at 1/"cpu MHz", which can be found by: "cat /proc/cpuinfo" > > > > - why are small delays only possible up to 2 msec? what if I needed a > > > delay of say 5msec? I can't get it? > > > > If you want other times, you can always make more than one call to > > nanosleep. > Good point! ~snip~ George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: sys_sched_yield fast path
On 10-Mar-2001 Mike Kravetz wrote: > Any thoughts about adding a 'fast path' to the SMP code in > sys_sched_yield. Why not compare nr_pending to smp_num_cpus > before examining the aligned_data structures? Something like, > > if (nr_pending > smp_num_cpus) > goto set_resched_now; > > Where set_resched_now is a label placed just before the code > that sets the need_resched field of the current process. > This would eliminate touching all the aligned_data cache lines > in the case where nr_pending can never be decremented to zero. > > Also, would it make sense to stop decrementing nr_pending to > prevent it from going negative? OR Is the reasoning that in > these cases there is so much 'scheduling' activity that we > should force the reschedule? Probably the rate at which is called sys_sched_yield() is not so high to let the performance improvement to be measurable. If You're going to measure the schedule() speed with the test program in which the schedule() rate is the same of the sched_yield() rate, this could clean Your measure of the schedule() speed. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ACPI:system description tables not found.
On Thu, 8 Mar 2001, Grover, Andrew wrote: > download the pmtools package from > http://developer.intel.com/technology/iapc/acpi/downloads.htm . (It's at the > bottom.) The acpidmp utility is what you're interested in (you can ignore > compile errors from the others.) Does this utility find tables, or not? > > Thanks -- Regards -- Andy I got the utility and compiled it under 2.4.2-ac12. No problem wit that. Acpidump reports: acpidump: cannot find an RSDP (Is ACPI enabled?). Yes ACPI is enabled in the system bios. Motherboard is P6DBU (Supermicro) with Dual P3 @ 450MHz. Stephen --- Buyer's Guide for a Operating System: Don't care to know: Mac Don't mind knowing but not too much: Windows Hit me! I can take it!: Linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ACPI:system description tables not found.
On Thu, 8 Mar 2001, David Christensen wrote: > Stephen, > > Is there a BIOS setup option for enabling ACPI? Make sure it is enabled. The BIOS setup option for ACPI is enabled. > Also attach a copy of the E820 output from dmesg. Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 SMP Mon Feb 26 23:47:16 GMT 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 17f0 @ 0010 (usable) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0004 @ fffc (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000fb4f0 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f2000 reserved twice. hm, page 000f3000 reserved twice. On node 0 totalpages: 98304 zone(0): 4096 pages. zone(1): 94208 pages. zone(2): 0 pages. Stephen --- Buyer's Guide for a Operating System: Don't care to know: Mac Don't mind knowing but not too much: Windows Hit me! I can take it!: Linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HP Vectra XU 5/90 interrupt problems
I'm having a problem with kernel 2.4.2-SMP on my HP Vectra XU 5/90. This is an old dual-pentium (Neptune chipset) machine. The machine has an on-board SCSI and ethernet controller, and I have added a Netgear FA310TX card. Due to the "unique" design of the motherboard, all the PCI slots share an interrupt with the SCSI controller. I have narrowed the problem down to the fact that the kernel is assigning the PCI devices edge-triggered interrupts (IO-APIC-edge) instead of level (IO-APIC-level). This causes the SCSI controller to hang if there is any network activity during disk activity. The machine identifies itself as an MPC type #5 machine (ISA/PCI), but it seems to have EISA-style ELCR configuration information. If I hack mpparse.c to force my machine type to #6 (EISA), the PCI interrupts are correctly identified as level triggered. Could someone please help me develop a correct workaround for this problem? I have been thinking about the following options: If there is no MP-table interrupt configuration information for an ISA/PCI system, try falling back to ELCR information before giving up and using a standard "ISA" scheme? It seems that HP may have done this on several of their early SMP systems. OR If PCI interrupts are shared, force them to be level triggered? Can shared PCI interrupts be edge triggered? If not, then wouldn't this be the correct solution? This isn't specific to the Vectra, but could possibly prevent problems on any machine with a broken BIOS? "/proc/interrupts" on the hacked kernel looks like: CPU0 CPU1 0: 411243 337583IO-APIC-edge timer 1: 1095 1260IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 4:603116IO-APIC-edge serial 5: 21400 20657IO-APIC-edge soundblaster 8: 0 2IO-APIC-edge rtc 9: 3398 3158 IO-APIC-level PCnet/PCI 79C970 10: 504852 505145 IO-APIC-level tmscsim, eth1 NMI: 749766 749768 LOC: 748736 748797 ERR: 0 I can post the dmesg output, if that would help. _ Get your FREE download of MSN Explorer at http://explorer.msn.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/
