* Compile error caused by case of filename extension
From: Shriramana Sharma @ 2006-03-25 8:03 UTC (permalink / raw)
To: Linux C Programming List
When the contents of TESTING.C are:
#include "stdio.h"
void main(void)
{
printf("\n%d\n", ( -0.25 < 0) ? 2 : 4);
}
Upon trying to compile:
$ gcc -o TESTING TESTING.C
TESTING.C:3: error: ‘::main’ must return ‘int’
Then I changed the file to:
#include "stdio.h"
int main(void)
{
printf("\n%d\n", ( -0.25 < 0) ? 2 : 4);
return 1;
}
Then I got:
$ gcc -o TESTING TESTING.C
/tmp/ccEnQk4o.o:(.eh_frame+0x11): undefined reference to
`__gxx_personality_v0'
collect2: ld returned 1 exit status
But if I change the input file name extension to testing.c or even TESTING.c
(small letters) no problems were got. Why is this?
--
Tux #395953 resides at http://samvit.org
playing with KDE 3.51 on SUSE Linux 10.0
$ date [] CCE +2006-03-25 W12-6 UTC+0530
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Fix branch ancestry calculation
From: Keith Packard @ 2006-03-25 7:54 UTC (permalink / raw)
To: Chris Shoemaker
Cc: keithp, Linus Torvalds, David Mansfield, David Mansfield,
Git Mailing List
In-Reply-To: <20060325014532.GB32522@pe.Belkin>
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
On Fri, 2006-03-24 at 20:45 -0500, Chris Shoemaker wrote:
> If that last sentence was a typo then you already know this, but
> otherwise you may be disappointed to learn that it's not _always_
> possible to discern the correct ancestry tree.
Sure, it's possible to generate trees which can't be figured out. So
far, I haven't found any which can't be pieced back together, except in
cases where the tree was accidentally damaged (child branches created on
two separate parent branches)
> If you end up comparing the ancestry tree discovered by your tool and
> the tree output by a patched cvsps, I would be very interested in the
> results.
So far, I've found several concrete trees where cvsps (in any form)
assigns branch points many versions too early compared to the 'true'
history. My tool is getting better answers, but still can't compute the
tree for the X.org X server tree yet. That one has a wide variety of
damage, including the direct copying of ,v files between repositories
which had divered, and the accidental branching of files from different
parent branches. I keep poking at it...
> -chris
>
> (*) You can distinguish between A->B->head and B->A->head simply by
> date.
I'm doing a lot more date-based identification than I'm really
comfortable with; the bad thing here is that branch points can occur
long before any commits to that branch, when doing date-based
operations, you have a range of possible matching branch points and it's
hard to disambiguate.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* IDE sysfs corrupted (second IDE channel parent lost) after resume from STR
From: Andrey Borzenkov @ 2006-03-25 7:51 UTC (permalink / raw)
To: linux-ide; +Cc: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This can be reproduced both in 2.6.15.6 and 2.6.16. Toshiba with Ali chipset,
driver compiled in as module. After system resumed from suspend-to-ram,
second channel of IDE controller loses its parent.
Before suspend:
total 0
lrwxrwxrwx 1 root root 0 Mar 25 10:38 0.0
- -> ../../../devices/pci0000:00/0000:00:04.0/ide0/0.0/
lrwxrwxrwx 1 root root 0 Mar 25 10:38 1.0
- -> ../../../devices/pci0000:00/0000:00:04.0/ide1/1.0/
After resume:
total 0
lrwxrwxrwx 1 root root 0 Mar 25 10:38 0.0
- -> ../../../devices/pci0000:00/0000:00:04.0/ide0/0.0/
lrwxrwxrwx 1 root root 0 Mar 25 10:41 1.0 -> ../../../devices/ide1/1.0/
I include dmesg output from 2.6.16; it can be seen that at least for second
channel probe_hwif() is called but apparently at this time it does not have
proper ->pci_dev set; I could find call chain that would have lead to this.
Please let me know if more information (like config or lspci) are needed.
Kernel does not contain binary drivers :)
Regards
- -andreyLinux version 2.6.16-2avb (bor@cooker.home.net) (gcc version 4.0.3
(4.0.3-1mdk for Mandriva Linux release 2006.1)) #4 Tue Mar 21 22:26:51 MSK
2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 00000000000eee00 (reserved)
BIOS-e820: 00000000000eee00 - 00000000000ef000 (ACPI NVS)
BIOS-e820: 00000000000ef000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ef60000 (usable)
BIOS-e820: 000000001ef60000 - 000000001ef70000 (ACPI data)
BIOS-e820: 000000001ef70000 - 0000000020000000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
495MB LOWMEM available.
On node 0 totalpages: 126816
DMA zone: 4096 pages, LIFO batch:0
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 122720 pages, LIFO batch:31
HighMem zone: 0 pages, LIFO batch:0
DMI 2.3 present.
ACPI: RSDP (v000 TOSHIB ) @ 0x000f0090
ACPI: RSDT (v001 TOSHIB 750 0x00970814 TASM 0x04010000) @ 0x1ef60000
ACPI: FADT (v002 TOSHIB 750 0x00970814 TASM 0x04010000) @ 0x1ef60054
ACPI: DSDT (v001 TOSHIB 4000 0x20020417 MSFT 0x0100000a) @ 0x00000000
ACPI: PM-Timer IO Port: 0xee08
Allocating PCI resources starting at 30000000 (gap: 20000000:dff80000)
Built 1 zonelists
Kernel command line: root=/dev/hda2 pinit hdc=ide-cd resume=/dev/hda1
splash=silent elevator=cfq vga=791
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (013e2000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 747.770 MHz processor.
Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 498992k/507264k available (1885k kernel code, 7628k reserved, 565k
data, 196k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1498.62 BogoMIPS
(lpj=2997249)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0387f9ff 00000000 00000000 00000000
00000000 00000000 00000000
CPU: After vendor identify, caps: 0387f9ff 00000000 00000000 00000000 00000000
00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU serial number disabled.
CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 00000000
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Coppermine) stepping 0a
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0a00)
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 324k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfe5ae, last bus=5
PCI: Using configuration type 1
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region ee00-ee3f claimed by ali7101 ACPI
PCI quirk: region ef00-ef1f claimed by ali7101 SMB
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: Power Resource [PFAN] (off)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: f7f00000-fdffffff
PREFETCH window: 3c000000-3c0fffff
PCI: Bus 2, cardbus bridge: 0000:00:10.0
IO window: 00001000-000010ff
IO window: 00001400-000014ff
PREFETCH window: 30000000-31ffffff
MEM window: 32000000-33ffffff
PCI: Bus 6, cardbus bridge: 0000:00:11.0
IO window: 00001800-000018ff
IO window: 00001c00-00001cff
PREFETCH window: 34000000-35ffffff
MEM window: 36000000-37ffffff
PCI: Bus 10, cardbus bridge: 0000:00:11.1
IO window: 00002000-000020ff
IO window: 00002400-000024ff
PREFETCH window: 38000000-39ffffff
MEM window: 3a000000-3bffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
PCI: Enabling device 0000:00:10.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKC] -> GSI 11 (level, low) ->
IRQ 11
PCI: Enabling device 0000:00:11.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 11 (level, low) ->
IRQ 11
PCI: Enabling device 0000:00:11.1 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.1[B] -> Link [LNKB] -> GSI 11 (level, low) ->
IRQ 11
audit: initializing netlink socket (disabled)
audit(1143268855.064:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Activating ISA DMA hang workarounds.
vesafb: framebuffer at 0xfc000000, mapped to 0xdf880000, using 3072k, total
16384k
vesafb: mode is 1024x768x16, linelength=2048, pages=9
vesafb: protected mode interface info at c000:775e
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Real Time Clock Driver v1.12ac
PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 2
input: AT Translated Set 2 keyboard as /class/input/input0
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 6, 262144 bytes)
TCP bind hash table entries: 16384 (order: 6, 327680 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
Using IPI Shortcut mode
swsusp: Resume From Partition /dev/hda1
PM: Checking swsusp image.
swsusp: Error -6 check for resume file
PM: Resume from disk failed.
ACPI wakeup devices:
COM USB1 ASND VIY0 VIY1 LAN MPC0 MPC1 NOV0 LID
ACPI: (supports S0 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller at PCI slot 0000:00:04.0
ACPI: PCI Interrupt 0000:00:04.0[A]: no GSI
ALI15X3: chipset revision 195
ALI15X3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xeff0-0xeff7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xeff8-0xefff, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: IC25N020ATDA04-0, ATA DISK drive
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: TOSHIBA DVD-ROM SD-C2502, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 39070080 sectors (20003 MB) w/1806KiB Cache, CHS=38760/16/63, UDMA(33)
hda: cache flushes not supported
hda: hda1 hda2
ReiserFS: hda2: found reiserfs format "3.6" with standard journal
ReiserFS: hda2: using ordered data mode
ReiserFS: hda2: journal params: device hda2, size 8192, journal first block
18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda2: checking transaction log (hda2)
ReiserFS: hda2: Using r5 hash to sort names
Freeing unused kernel memory: 196k freed
Write protecting the kernel read-only data: 266k
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKG] -> GSI 11 (level, low) ->
IRQ 11
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:02.0: irq 11, io mem 0xf7eff000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKC] -> GSI 11 (level, low) ->
IRQ 11
Yenta: CardBus bridge found at 0000:00:10.0 [12a3:ab01]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:10.0, mfunc 0x01000002, devctl 0x60
Yenta: ISA IRQ mask 0x0000, PCI irq 11
Socket status: 30000059
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 11 (level, low) ->
IRQ 11
Yenta: CardBus bridge found at 0000:00:11.0 [1179:0001]
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000007
pccard: PCMCIA card inserted into slot 0
cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xcbfff 0xe0000-0xfffff
cs: memory probe 0x60000000-0x60ffffff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
pcmcia: registering new device pcmcia0.0
ACPI: PCI Interrupt 0000:00:11.1[B] -> Link [LNKB] -> GSI 11 (level, low) ->
IRQ 11
Yenta: CardBus bridge found at 0000:00:11.1 [1179:0001]
wlags49_h1_cs v7.18 for PCMCIA, 03/31/2004 14:31:00 by Agere Systems,
http://www.agere.com
*** Modified for kernel 2.6 by Andrey Borzenkov <arvidjaar@mail.ru> $Revision:
19 $
*** Station Mode (STA) Support: YES
*** Access Point Mode (AP) Support: YES
eth0: PRI 31 variant 2 version 9.48
eth0: NIC 5 variant 2 version 1.02
eth0: Wireless, io_addr 0x100, irq 11, mac_address 00:02:2D:26:95:6C
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000007
ts: Compaq touchscreen protocol output
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected ALi M1644 chipset
agpgart: AGP aperture is 64M @ 0xf0000000
ACPI: AC Adapter [ADP1] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Battery Slot [BAT2] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Fan [FAN] (off)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Thermal Zone [THRM] (49 C)
toshiba_acpi: Toshiba Laptop ACPI Extras version 0.18
toshiba_acpi: HCI method: \_SB_.VALD.GHCI
ACPI: Video Device [VGA] (multi-head: yes rom: yes post: no)
Adding 500432k swap on /dev/hda1. Priority:-1 extents:1 across:500432k
loop: loaded (max 8 devices)
hdc: ATAPI 24X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
process `syslogd' is using obsolete setsockopt SO_BSDCOMPAT
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKH] -> GSI 11 (level, low) ->
IRQ 11
NET: Registered protocol family 17
pcmcia: Detected deprecated PCMCIA ioctl usage.
pcmcia: This interface will soon be removed from the kernel; please expect
breakage unless you upgrade to new tools.
pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html
for details.
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKD] -> GSI 11 (level, low) ->
IRQ 11
e100: eth0: e100_probe: addr 0xf7efd000, irq 11, MAC addr 00:00:39:D7:14:A1
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
i2c_adapter i2c-0: Error: command never completed
i2c_adapter i2c-0: Adapter hung, retrying after reset
i2c_adapter i2c-0: Error: command never completed
i2c_adapter i2c-0: Adapter hung, retrying after reset
i2c_adapter i2c-0: Error: command never completed
i2c_adapter i2c-0: Adapter hung, retrying after reset
========== suspend start ======================
ACPI: PCI interrupt for device 0000:00:06.0 disabled
ACPI: PCI interrupt for device 0000:00:0a.0 disabled
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKD] -> GSI 11 (level, low) ->
IRQ 11
e100: eth0: e100_probe: addr 0xf7efd000, irq 11, MAC addr 00:00:39:D7:14:A1
pccard: card ejected from slot 0
PM: Preparing system for mem sleep
Stopping tasks:
==================================================================================|
pnp: Device 00:09 disabled.
ACPI: PCI interrupt for device 0000:00:11.1 disabled
ACPI: PCI interrupt for device 0000:00:11.0 disabled
ACPI: PCI interrupt for device 0000:00:10.0 disabled
ACPI: PCI interrupt for device 0000:00:0a.0 disabled
ACPI: PCI interrupt for device 0000:00:02.0 disabled
PM: Entering mem sleep
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Back to C!
Debug: sleeping function called from invalid context
at /home/bor/src/linux-git/mm/slab.c:2729
in_atomic():0, irqs_disabled():1
[<c0104213>] show_trace+0x13/0x20
[<c010423e>] dump_stack+0x1e/0x20
[<c0116032>] __might_sleep+0xa2/0xc0
[<c015c533>] kmem_cache_alloc+0x53/0x70
[<c01f2a53>] acpi_os_acquire_object+0x11/0x41
[<c020843f>] acpi_ut_allocate_object_desc_dbg+0xf/0x44
[<c02084cb>] acpi_ut_create_internal_object_dbg+0x16/0x6a
[<c0204807>] acpi_rs_set_srs_method_data+0x40/0xb9
[<c0203f05>] acpi_set_current_resources+0x23/0x2e
[<c020bd7b>] acpi_pci_link_set+0xff/0x17b
[<c020be2e>] irqrouter_resume+0x37/0x56
[<c0236b8a>] __sysdev_resume+0x1a/0x90
[<c0236c47>] sysdev_resume+0x47/0x70
[<c023c648>] device_power_up+0x8/0x10
[<c0138b7a>] enter_state+0x1ba/0x220
[<c0138c77>] state_store+0x97/0xb0
[<c01a188e>] subsys_attr_store+0x2e/0x30
[<c01a1e63>] sysfs_write_file+0xb3/0x100
[<c015fe57>] vfs_write+0xa7/0x190
[<c0160867>] sys_write+0x47/0x70
[<c0102f07>] sysenter_past_esp+0x54/0x75
PM: Finishing wakeup.
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKG] -> GSI 11 (level, low) ->
IRQ 11
ACPI: PCI Interrupt 0000:00:04.0[A]: no GSI
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKC] -> GSI 11 (level, low) ->
IRQ 11
pccard: PCMCIA card inserted into slot 0
pcmcia: registering new device pcmcia0.0
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
eth1: Wireless, io_addr 0x100, irq 11, mac_address 00:02:2D:26:95:6C
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 11 (level, low) ->
IRQ 11
ACPI: PCI Interrupt 0000:00:11.1[B] -> Link [LNKB] -> GSI 11 (level, low) ->
IRQ 11
pnp: Failed to activate device 00:05.
pnp: Failed to activate device 00:06.
pnp: Device 00:09 activated.
usb usb1: root hub lost power or was reset
Restarting tasks... done
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period
NET: Registered protocol family 23
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKH] -> GSI 11 (level, low) ->
IRQ 11
Probing IDE interface ide1...
hdc: TOSHIBA DVD-ROM SD-C2502, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: ATAPI 24X DVD-ROM drive, 128kB Cache
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEJPZvR6LMutpd94wRAoLqAJ0UxvE3WGtDsreVeql2xhAmpmKHbgCgxiDh
kspfyJ6bWdSfXrfsLuyGAC0=
=vbuO
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: eCryptfs Design Document
From: Miklos Szeredi @ 2006-03-25 7:38 UTC (permalink / raw)
To: akpm
Cc: mhalcrow, phillip, linux-kernel, linux-fsdevel, viro, mike,
mcthomps, yoder1, toml, emilyr, daw
In-Reply-To: <20060324163358.557ac5f7.akpm@osdl.org>
> > > One dutifully wonders whether all this functionality could be
> > > provided via FUSE...
> >
> > My main concern with FUSE has to do with shared memory mappings.
>
> OK. But I'm sure Miklos would appreciate help with that ;)
You bet.
> > My next concern is with regard to performance impact of constant
> > context switching during page reads and writes.
>
> Maybe. One could estimate the cost of that by benchmarking an existing
> (efficient) FUSE fs and then add fiddle factors. If the number of copies
> is the same for in-kernel versus FUSE then one would expect the performance
> to be similar. Especially if the encrypt/decryption cost perponderates.
The main overhead of FUSE is not in copies, but in context switching.
For I/O that can be mitigated by doing it in big chunks, otherwise the
only solution is adding more processors.
Miklos
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Junio C Hamano @ 2006-03-25 7:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vk6ajxbe5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> This uses a simplified libxdiff setup to generate unified diffs _without_
>> doing fork/execve of GNU "diff".
>
> Good stuff.
The reason I like this is because I was thinking about doing
in-core diffs for different purpose when I was driving to work
this morning [*1*] --- to make pickaxe a more useful building
block.
Currently, pickaxe tries to do an exact match to find the case
where a given substring S appears in the version C of the file
but not in the its parent C^n (1 <= n), and then it tells the
diffcore to emit the differences. The user (probably only me on
this list?) is expected to look at the change, make an
intelligent decision to feed a matching substring S' found in
C^n and restart from that commit.
To be a useful "content movement tracker", the process of
finding matching 'old shape' in the previous version and
re-feeding it to pickaxe should be automated if possible, and
in-core diff machinery would be one component to help that.
For example, if I wanted to find when I stole 'ls-files -t'
feature from Cogito, I would first run less ls-files.c; I see
these and am reasonably sure these relate to what I am looking
for:
...
static const char *tag_cached = "";
static const char *tag_unmerged = "";
static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";
static const char *tag_modified = "";
...
So I run:
$ git whatchanged -S'static const char *tag_other = "";
static const char *tag_killed = "";
static const char *tag_modified' -p master -- ls-files.c
which finds:
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Sep 19 15:11:15 2005 -0700
Show modified files in git-ls-files
...
@@ -28,6 +29,7 @@ static const char *tag_unmerged = "";
static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";
+static const char *tag_modified = "";
but that is not what I am interested in; the matching "old
shape" is the version before the tag_modified was added (and it
already had other tag_xxx in there). So with the current
pickaxe, I manually re-run whatchanged starting from the found
commit with modified string like this:
$ git whatchanged -S'static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";' -p $that_commit -- ls-files.c
in order to further drill down.
A truly useful pickaxe should take two line numbers and a
filename (to name the range of lines I am interested in) from
the starting version, notice when that range changes shape, and
after showing the found commit, replace the range with the one
matching from the older commit and continue.
[Footnote]
*1* When you are bogged down in a boring day-job, your brain
tends to try to compensate by spending as much your waking time
as possible on thinking about more interesting and more useful
stuff -- like git ;-).
^ permalink raw reply
* [ALSA - driver 0001964]: CMedia 9880 ECS 915p-a 1.2a NO MIC/LINE IN
From: bugtrack @ 2006-03-25 7:38 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1964>
======================================================================
Reported By: sharpen047
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1964
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution:
Kernel Version:
======================================================================
Date Submitted: 03-25-2006 08:24 CET
Last Modified: 03-25-2006 08:38 CET
======================================================================
Summary: CMedia 9880 ECS 915p-a 1.2a NO MIC/LINE IN
Description:
alsa mixer is up tried for about 2 months now to fix this... i dont know
what to do tell me what to post and youll get it
thanks!
======================================================================
----------------------------------------------------------------------
sharpen047 - 03-25-06 08:38
----------------------------------------------------------------------
localhost ~ # modprobe snd-hda-intel
WARNING: Error inserting snd_timer
(/lib/modules/2.6.15-gentoo-r1/kernel/sound/acore/snd-timer.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
WARNING: Error inserting snd_pcm
(/lib/modules/2.6.15-gentoo-r1/kernel/sound/acore/snd-pcm.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting snd_hda_intel
(/lib/modules/2.6.15-gentoo-r1/alsa-driver/pci/snd-hda-intel.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
Issue History
Date Modified Username Field Change
======================================================================
03-25-06 08:24 sharpen047 New Issue
03-25-06 08:38 sharpen047 Note Added: 0008943
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* RE: 2.6.16 hugetlbfs problem - DEBUG_PAGEALLOC
From: Chen, Kenneth W @ 2006-03-25 7:29 UTC (permalink / raw)
To: 'Andrew Morton'; +Cc: mrustad, linux-kernel
In-Reply-To: <20060324185331.56837b0a.akpm@osdl.org>
Andrew Morton wrote on Friday, March 24, 2006 6:54 PM
> "Chen, Kenneth W" <kenneth.w.chen@intel.com> wrote:
> >
> > Mark Rustad wrote on Friday, March 24, 2006 9:52 AM
> > > I have narrowed this down to DEBUG_PAGEALLOC. If that option is
> > > enabled, attempts to reference areas mmap-ed from hugetlbfs files
> > > fault forever. You can see that I had that set in the failing config
> > > I reported below.
> >
> > Yeah, it turns out that the debug option is not compatible with hugetlb
> > page support. That debug option turns off PSE. Once it is turned off in
> > CR4, cpu will ignore pse bit in the pmd and causing infinite page-not-
> > present fault :-(
>
> I wonder if any of the other architectures which implement both these
> features might have problems too.
Only 32-bit x86 arch implements both. We get away by not having DEBUG_PAGEALLOC
feature on any other arch.
I read the ia32 processor manual, it says the pse flag in CR4 controls
4K/4M mapping in addition to pse bit in page directory entry. But in
PAE mode, cr4.pse is ignored and pse bit in pmd controls 4K/2M mapping.
I was going to verify that on my ia32 box, but apparently, turning on
64G highmem gives me machine reset at boot. (is it a known regression?)
X86-64 surly ignores cr4.pse for 4K/2M mapping. It is solely controlled
by pse bit in pmd.
- Ken
^ permalink raw reply
* [ALSA - driver 0001964]: CMedia 9880 ECS 915p-a 1.2a NO MIC/LINE IN
From: bugtrack @ 2006-03-25 7:24 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1964>
======================================================================
Reported By: sharpen047
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1964
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution:
Kernel Version:
======================================================================
Date Submitted: 03-25-2006 08:24 CET
Last Modified: 03-25-2006 08:24 CET
======================================================================
Summary: CMedia 9880 ECS 915p-a 1.2a NO MIC/LINE IN
Description:
alsa mixer is up tried for about 2 months now to fix this... i dont know
what to do tell me what to post and youll get it
thanks!
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
03-25-06 08:24 sharpen047 New Issue
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [PATCH] Fixed build error with debug=y
From: Masaki Kanno @ 2006-03-25 7:22 UTC (permalink / raw)
To: xen-devel, xen-ia64-devel
[-- Attachment #1: Type: text/plain, Size: 202 bytes --]
Hi,
This patch fixed build error with debug=y in the xen/ia64.
The MAX_ORDER definition has moved into the header file.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Best regards,
Kan
[-- Attachment #2: MAX_ORDER.patch --]
[-- Type: application/octet-stream, Size: 992 bytes --]
diff -r 2e81aba147eb xen/common/page_alloc.c
--- a/xen/common/page_alloc.c Fri Mar 24 11:36:22 2006 -0700
+++ b/xen/common/page_alloc.c Sat Mar 25 16:15:56 2006 +0900
@@ -219,8 +219,6 @@ unsigned long alloc_boot_pages(unsigned
#define pfn_dom_zone_type(_pfn) \
(((_pfn) <= MAX_DMADOM_PFN) ? MEMZONE_DMADOM : MEMZONE_DOM)
-/* Up to 2^20 pages can be allocated at once. */
-#define MAX_ORDER 20
static struct list_head heap[NR_ZONES][MAX_ORDER+1];
static unsigned long avail[NR_ZONES];
diff -r 2e81aba147eb xen/include/xen/mm.h
--- a/xen/include/xen/mm.h Fri Mar 24 11:36:22 2006 -0700
+++ b/xen/include/xen/mm.h Sat Mar 25 16:15:56 2006 +0900
@@ -68,6 +68,9 @@ unsigned long avail_domheap_pages(void);
#define ALLOC_DOM_DMA 1
+/* Up to 2^20 pages can be allocated at once. */
+#define MAX_ORDER 20
+
/* Automatic page scrubbing for dead domains. */
extern struct list_head page_scrub_list;
#define page_scrub_schedule_work() \
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Effective difference between git-rebase and git-resolve
From: Junio C Hamano @ 2006-03-25 7:15 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20060325063225.GA13791@buici.com>
Marc Singer <elf@buici.com> writes:
[I'm shuffling this part to the top]
> Moreover, it isn't clear to me if git-rebase is better than git-merge.
Merge preserves commit ancestry, so if you are hoping it to
clean up your history, that is not the tool to do it. Both
rebase and cherry-pick are to help you create a cleaner,
alternate history. So none is better than the other. They
serve different purposes.
> On Fri, Mar 24, 2006 at 10:08:09PM -0800, Junio C Hamano wrote:
>> > Junio, is there some magic to restart a rebase after you've fixed up the
>> > conflicts?
>>
>> The modern rebase is essentially git-format-patch piped to
>> git-am (with -3 flag to allow falling back to three-way merge),
>> and all the familiar "the patch did not apply -- what now?"
>> techniques can be employed.
>...
> By modern do you mean newer than 1.2.4? I comprehend what you're
> layin' down here, but I don't know if I need to do something
> different.
By modern, I meant v0.99.9-g7f59dbb.
diff-tree 7f59dbb... (from f9039f3...)
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Nov 14 00:41:53 2005 -0800
Rewrite rebase to use git-format-patch piped to git-am.
The current rebase implementation finds commits in our tree but
not in the upstream tree using git-cherry, and tries to apply
them using git-cherry-pick (i.e. always use 3-way) one by one.
Which is fine, but when some of the changes do not apply
cleanly, it punts, and punts badly.
Suppose you have commits A-B-C-D-E since you forked from the
upstream and submitted the changes for inclusion. You fetch
from upstream head U and find that B has been picked up. You
run git-rebase to update your branch, which tries to apply
changes contained in A-C-D-E, in this order, but replaying of C
fails, because the upstream got changes that touch the same area
from elsewhere.
Now what?
It notes that fact, and goes ahead to apply D and E, and at the
very end tells you to deal with C by hand. Even if you somehow
managed to replay C on top of the result, you would now end up
with ...-B-...-U-A-D-E-C.
Breaking the order between B and others was the conscious
decision made by the upstream, so we would not worry about it,
and even if it were worrisome, it is too late for us to fix now.
What D and E do may well depend on having C applied before them,
which is a problem for us.
This rewrites rebase to use git-format-patch piped to git-am,
and when the patch does not apply, have git-am fall back on
3-way merge. The updated diff/patch pair knows how to apply
trivial binary patches as long as the pre- and post-images are
locally available, so this should work on a repository with
binary files as well.
The primary benefit of this change is that it makes rebase
easier to use when some of the changes do not replay cleanly.
In the "unapplicable patch in the middle" case, this "rebase"
works like this:
- A series of patches in e-mail form is created that records
what A-C-D-E do, and is fed to git-am. This is stored in
.dotest/ directory, just like the case you tried to apply
them from your mailbox. Your branch is rewound to the tip of
upstream U, and the original head is kept in .git/ORIG_HEAD,
so you could "git reset --hard ORIG_HEAD" in case the end
result is really messy.
- Patch A applies cleanly. This could either be a clean patch
application on top of rewound head (i.e. same as upstream
head), or git-am might have internally fell back on 3-way
(i.e. it would have done the same thing as git-cherry-pick).
In either case, a rebased commit A is made on top of U.
- Patch C does not apply. git-am stops here, with conflicts to
be resolved in the working tree. Yet-to-be-applied D and E
are still kept in .dotest/ directory at this point. What the
user does is exactly the same as fixing up unapplicable patch
when running git-am:
- Resolve conflict just like any merge conflicts.
- "git am --resolved --3way" to continue applying the patches.
- This applies the fixed-up patch so by definition it had
better apply. "git am" knows the patch after the fixed-up
one is D and then E; it applies them, and you will get the
changes from A-C-D-E commits on top of U, in this order.
I've been using this without noticing any problem, and as people
may know I do a lot of rebases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* Modify the sock Structure!!
From: Benjamin @ 2006-03-25 7:11 UTC (permalink / raw)
To: linux-kernel
Hello! I try to modify the sock Structure in sock.h in order to record
some data!
I just add a unsigned short in the end of the structure. such as:
struct sock {
/* Socket demultiplex comparisons on incoming packets. */
__u32 daddr; /* Foreign IPv4 addr */
__u32 rcv_saddr; /* Bound local IPv4 addr */
...................................................................
....................................................................
void (*destruct)(struct sock *sk);
unsigned short data; /*I put the unsigned short
here*/
};
I re-complied the kernel. The kernel and network functions work
normally so far.
However, I am a new guy for the kernel programming. I just wonder this
modification is
safe or not. Is there any side-effect? Or I need to add additional code
to avoid some unexpected
situation? Thank you very much!
^ permalink raw reply
* Re: what's the right way to do this in 2.6?
From: Sam Ravnborg @ 2006-03-25 7:05 UTC (permalink / raw)
To: evt; +Cc: linux-kernel
In-Reply-To: <W433413418255631143243608@webmail13>
On Fri, Mar 24, 2006 at 11:40:08PM +0000, evt@texelsoft.com wrote:
> I have two modules that need to share a common utility library. What
> I'd like to do is make the library into a .a and link each module to it.
> 'Twould be also nice if the modules had a dependency so the library
> got built automatically. Thanks for any advice.
Drop the library idea and create a third module.
That's how this is done in several places in the kernel with success.
See Documentation/kbuild/* for how to deal with more than one module.
Sam
^ permalink raw reply
* Re: [PATCH] powerpc: legacy_serial loop cleanup
From: Stephen Rothwell @ 2006-03-25 7:05 UTC (permalink / raw)
To: Michael Neuling; +Cc: michael, linuxppc-dev
In-Reply-To: <20060325044501.D32A267A58@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
On Sat, 25 Mar 2006 15:45:11 +1100 Michael Neuling <mikey@neuling.org> wrote:
>
> Agreed. Updated patch below.
> .
> .
> +static void __init setup_legacy_serial_console(int console)
> +{
> + struct legacy_serial_info *info =
> + &legacy_serial_infos[legacy_serial_console];
Except that you don't want to do that ^ (assuming you meant "console")
> + void __iomem *addr;
> +
> + if (console < 0)
> + return;
before this ^ ... :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] Call get_time() only when necessary in run_hrtimer_queue
From: Thomas Gleixner @ 2006-03-25 7:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Dimitri Sivanich, linux-kernel, mingo, roe, steiner, clameter
In-Reply-To: <20060324142849.5cc27edb.akpm@osdl.org>
On Fri, 2006-03-24 at 14:28 -0800, Andrew Morton wrote:
> This code has been extensively redone in -mm and I am planning on sending
> all that to Linus within a week.
>
> The hrtimer rework in -mm might fix this performance problem, although from
> a quick peek, perhaps not.
>
> So could you please verify that the problem still needs fixing in
> 2.6.16-mm1 and if so, raise a patch against that?
I have a look into it.
tglx
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Junio C Hamano @ 2006-03-25 6:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603241938510.15714@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This uses a simplified libxdiff setup to generate unified diffs _without_
> doing fork/execve of GNU "diff".
Good stuff.
> Now, in the interest of full disclosure, I should also point out a few
> downsides:
>
> - the libxdiff algorithm is different,...
>
> - GNU diff does some nice eye-candy, like trying to figure out what the
> last function was, and adding that information to the "@@ .." line.
> libxdiff doesn't do that.
That's kind of sad --- Documentation/SubmittingPatches request
people to say "diff -u -p".
> - The libxdiff thing has some known deficiencies. In particular, it gets
> the "\No newline at end of file" case wrong. So this is currently for
> the experimental branch only. I hope Davide will help fix it.
Another thing I noticed is that while libxdiff always shows full
line counts "-n,m +l,k" GNU seems to omit them when it can (m,k
<=1). I am not sure if apply.c is set up to grok what libxdiff
emits correctly. Running t/t1200 shows some obvious examples.
^ permalink raw reply
* [patch 21/20] Fix speedstep-smi assembly bug in speedstep_smi_ownership
From: Greg KH @ 2006-03-25 6:48 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Theodore Ts'o, Zwane Mwaikambo, Justin Forbes, torvalds,
Randy Dunlap, Dave Jones, Chuck Wolber, alan, ospite, davej
In-Reply-To: <20060325042556.GA21260@kroah.com>
One more last minute patch...
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andrew Morton <akpm@osdl.org>
Fix bug identified by Linus Torvalds <torvalds@osdl.org>: the `out'
instruction depends upon the state of memory_data[], so we need to tell gcc
that before executing it. (The opcode, not gcc).
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=5553
Thanks to Antonio Ospite <ospite@studenti.unina.it> for testing.
Cc: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/i386/kernel/cpu/cpufreq/speedstep-smi.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
diff -puN arch/i386/kernel/cpu/cpufreq/speedstep-smi.c~cpufreq-speedstep-smi-asm-fix arch/i386/kernel/cpu/cpufreq/speedstep-smi.c
--- devel/arch/i386/kernel/cpu/cpufreq/speedstep-smi.c~cpufreq-speedstep-smi-asm-fix 2006-03-24 10:35:45.000000000 -0800
+++ devel-akpm/arch/i386/kernel/cpu/cpufreq/speedstep-smi.c 2006-03-24 10:36:07.000000000 -0800
@@ -75,7 +75,9 @@ static int speedstep_smi_ownership (void
__asm__ __volatile__(
"out %%al, (%%dx)\n"
: "=D" (result)
- : "a" (command), "b" (function), "c" (0), "d" (smi_port), "D" (0), "S" (magic)
+ : "a" (command), "b" (function), "c" (0), "d" (smi_port),
+ "D" (0), "S" (magic)
+ : "memory"
);
dprintk("result is %x\n", result);
_
^ permalink raw reply
* Re: State of userland headers
From: Kyle Moffett @ 2006-03-25 6:48 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: nix, rob, mmazur, linux-kernel, llh-discuss
In-Reply-To: <20060324150100.ec96dc15.rdunlap@xenotime.net>
On Mar 24, 2006, at 18:01:00, Randy.Dunlap wrote:
> Kyle,
> Do you have (recorded) or recall any constraints or requirements on
> this $subject from Linus or Andrew or others? I mean just basic
> big items, like "thou shalt not mix foo and bar".
>
> I'm just looking for the basic parameters of this task.
Well, to a large extent he's actually wisely kind of stayed out of
the flamewars :-D I'm guessing he's hoping that we'll figure
something acceptable out on our own and send him patches without him
having to think about it much. He has said this, though:
> On the bigger question of what to do with kernel headers in
> general, let's just make one thing clear: the kernel headers are
> for the kernel, and big and painful re-organizations that don't
> help _existing_ user space are not going to happen.
He's also said this:
> On Tue, 30 Nov 2004, Alexandre Oliva wrote:
>> Then maybe this is the fundamental problem. As long as the kernel
>> doesn't recognize that an ABI is a contract, rather than an
>> imposition, kernel developers won't care.
>
> That's a silly analogy. Worse, it's a very flawed analogy.
>
> If you want to use a legal analogy, the ABI is not a contract, it's
> a public _license_.
>
> Why? A contract is something that you cannot change unilaterally.
> Clearly the kernel _can_ and will change the ABI without asking
> every existing program for permission.
>
> In a license, you can always just _expand_ the license eventually.
> Maybe you originally licensed for "fly-fishing for trout", and
> later you can expand that license to say "you can also catch
> crawfish" without impacting your existing licensees.
>
> And exactly as with an ABI, the only thing you can't do is _remove_
> rights without getting into trouble.
>
> So get your analogies straight. The kernel ABI is _not_ a contract.
My hope for this is that we can start doing _little_ and clearly
obvious changes that clean up header files. Basically a lot of the
__KERNEL__ definitions need janitorial work. Either they need to be
removed or they need to be put in the right places. Also it seems
like there's a lot of duplication between architectures; for one
example look at all the varieties of FD_SET code in the different
linux/include/asm-*/posix_types.h files. That's one of the areas I'm
trying to clean up into a single linux/fdset.h included from the
pertinent files. Notice how the file forcibly overrides GLIBC; I
think if we can define it as __KABI_FD* and only define the non-
prefixed version in __KERNEL__, then we can provide something that
GLIBC and klibc can get for free, without having to figure out their
own bitmaps. Likewise some of the user-accessible types are uniform
across architectures, and others are haphazardly arrayed, some to be
compatible with other OSes on that architecture, others just because
that's what the arch they copied from used. I'm hoping if I can get
enough small patches flowing, others will join in too and the process
will go easier.
Cheers,
Kyle Moffett
^ permalink raw reply
* [PATCH] quieten zone_pcp_init
From: Anton Blanchard @ 2006-03-25 6:41 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
In zone_pcp_init we print out all zones even if they are empty:
On node 0 totalpages: 245760
DMA zone: 245760 pages, LIFO batch:31
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 0 pages, LIFO batch:0
HighMem zone: 0 pages, LIFO batch:0
To conserve dmesg space why not print only the non zero zones.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: build/mm/page_alloc.c
===================================================================
--- build.orig/mm/page_alloc.c 2006-03-25 16:26:58.000000000 +1100
+++ build/mm/page_alloc.c 2006-03-25 16:27:06.000000000 +1100
@@ -2029,8 +2029,9 @@ static __meminit void zone_pcp_init(stru
setup_pageset(zone_pcp(zone,cpu), batch);
#endif
}
- printk(KERN_DEBUG " %s zone: %lu pages, LIFO batch:%lu\n",
- zone->name, zone->present_pages, batch);
+ if (zone->present_pages)
+ printk(KERN_DEBUG " %s zone: %lu pages, LIFO batch:%lu\n",
+ zone->name, zone->present_pages, batch);
}
static __meminit void init_currently_empty_zone(struct zone *zone,
^ permalink raw reply
* Re: [Sdhci-devel] Submission to the kernel?
From: Greg KH @ 2006-03-25 6:39 UTC (permalink / raw)
To: Pierre Ossman
Cc: Andrew Morton, Mark Lord, David J. Wallace, sdhci-devel,
linux-kernel
In-Reply-To: <4424D9CA.7090303@drzeus.cx>
On Sat, Mar 25, 2006 at 06:48:58AM +0100, Pierre Ossman wrote:
> Greg KH wrote:
> > Tried it out and it works great (also see it's in 2.6.16-git9 now). Hm,
> > my laptop's slot also supports xD cards, which your patch set does not
> > yet support, right?
> >
> >
>
> And will never do. Different hardware, interface and protocol.
Doh, you are right, sorry about that. It's a totally different PCI
device, I should have looked before writing that.
Anyway, thanks again, this is working fine here.
greg k-h
^ permalink raw reply
* Re: killing a pptp tunnel with a single ping
From: James Cameron @ 2006-03-25 6:36 UTC (permalink / raw)
To: linux-ppp
In-Reply-To: <20060324232128.GA23810@wonderland.linux.it>
I've tried but failed to reproduce this. Could you obtain and post the
pppd debug dump log showing the negotiation of the tunnel? That will
help to narrow the scope.
I've also done a test that excludes pptp, by using pppd over ssh, such
as:
# echo "test test test *" >> /etc/ppp/chap-secrets
# ssh peer 'echo "test test test *" >> /etc/ppp/chap-secrets'
# pppd noauth silent require-mppe name test remotename test debug dump
logfd 2 nodetach pty "ssh -t -e none peer pppd name test
require-mschap-v2 require-mppe 10.0.5.1:10.0.5.2"
But the ping as described did nothing wrong. 2.6.16 kernel.org.
Then again, what's the -M dont? My ping (Debian) doesn't have that.
--
James Cameron
^ permalink raw reply
* Re: State of userland headers
From: Kyle Moffett @ 2006-03-25 6:33 UTC (permalink / raw)
To: Jeff Dike; +Cc: Nix, Rob Landley, Mariusz Mazur, LKML Kernel, llh-discuss
In-Reply-To: <20060325013615.GD8117@ccure.user-mode-linux.org>
On Mar 24, 2006, at 20:36:15, Jeff Dike wrote:
> On Fri, Mar 24, 2006 at 05:46:27PM -0500, Kyle Moffett wrote:
>> 4) UML runs into a lot of problems when glibc's headers and the
>> native kernel headers headers conflict.
>>
>> UML has other issues with conflicts between the native kernel
>> headers and the GLIBC-provided stubs. It's been mentioned on the
>> prior threads about this topic that this sort of system would ease
>> most of the issues that UML runs into.
>
> Actually, this isn't quite the same as what UML hits. My problem
> with the kernel headers is that they are a mixture of things that
> are usable in userspace and things that aren't. This is closely
> related, but not identical to, things which are part of the ABI and
> things which aren't.
>
> For example, the kernel locks are quite usable in userspace, but
> you would never make them part of the ABI.
>
> So, a set of KABI headers would likely make UML's headers cleaner,
> by avoiding copying arch headers and using various nasty tricks to
> disable objectionable pieces of headers which I steal from the arch.
>
> So what I really want is a superset of the KABI headers, but the
> KABI will give me most of what I want.
So perhaps could we define an informal subset of the kernel code that
works in both userspace and kernel-space and put it in include/libk?
Stuff like linked lists, spinlocks (depends on arch, may not be
supported), etc could be in linux/libk and linux/include/libk or
similar, and then from there included into linux/include/linux/
list.h, etc, as well as into the UML files that need it. Since the
provider and user would both be the Linux kernel, I see no issues
with trying to provide a stable interface of any kind, especially if
we document it as "PRIVATE - FOR KERNEL USE ONLY!!!" with big warning
signs. As a nice bonus, this would make it possible to implement some
user-space unit tests of various pieces.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: Effective difference between git-rebase and git-resolve
From: Marc Singer @ 2006-03-25 6:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7v64m3ys3a.fsf@assigned-by-dhcp.cox.net>
On Fri, Mar 24, 2006 at 10:08:09PM -0800, Junio C Hamano wrote:
> > Junio, is there some magic to restart a rebase after you've fixed up the
> > conflicts?
>
> The modern rebase is essentially git-format-patch piped to
> git-am (with -3 flag to allow falling back to three-way merge),
> and all the familiar "the patch did not apply -- what now?"
> techniques can be employed.
>
> Since the pre-image blobs recorded in the intermediate
> format-patch output by definition exist in your repository, it
> always falls back to three-way merge when the patch does not
> apply cleanly. Then you can resolve and say "git am --resolved"
> to continue.
By modern do you mean newer than 1.2.4? I comprehend what you're
layin' down here, but I don't know if I need to do something
different.
Moreover, it isn't clear to me if git-rebase is better than git-merge.
^ permalink raw reply
* [PATCH] powerpc: Compile warning in hvcs driver
From: Anton Blanchard @ 2006-03-25 6:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
We ended up with an unused variable after the tty updates went in. Fix it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: build/drivers/char/hvcs.c
===================================================================
--- build.orig/drivers/char/hvcs.c 2006-03-25 16:26:57.000000000 +1100
+++ build/drivers/char/hvcs.c 2006-03-25 16:27:10.000000000 +1100
@@ -439,7 +439,6 @@ static int hvcs_io(struct hvcs_struct *h
char buf[HVCS_BUFF_LEN] __ALIGNED__;
unsigned long flags;
int got = 0;
- int i;
spin_lock_irqsave(&hvcsd->lock, flags);
^ permalink raw reply
* [PATCH] HVC init race
From: Anton Blanchard @ 2006-03-25 6:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey, paulus
From: Michael Neuling <mikey@neuling.org>
I've been hitting a crash on boot where tty_open is being called before the
hvc console driver setup is complete. Below patch fixes this problem.
Thanks to benh for his help on this.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Anton Blanchard <anton@samba.org>
---
Index: build/drivers/char/hvc_console.c
===================================================================
--- build.orig/drivers/char/hvc_console.c 2006-03-25 16:49:20.000000000 +1100
+++ build/drivers/char/hvc_console.c 2006-03-25 16:49:44.000000000 +1100
@@ -823,34 +823,38 @@ EXPORT_SYMBOL(hvc_remove);
* interfaces start to become available. */
int __init hvc_init(void)
{
+ struct tty_driver *drv;
+
/* We need more than hvc_count adapters due to hotplug additions. */
- hvc_driver = alloc_tty_driver(HVC_ALLOC_TTY_ADAPTERS);
- if (!hvc_driver)
+ drv = alloc_tty_driver(HVC_ALLOC_TTY_ADAPTERS);
+ if (!drv)
return -ENOMEM;
- hvc_driver->owner = THIS_MODULE;
- hvc_driver->devfs_name = "hvc/";
- hvc_driver->driver_name = "hvc";
- hvc_driver->name = "hvc";
- hvc_driver->major = HVC_MAJOR;
- hvc_driver->minor_start = HVC_MINOR;
- hvc_driver->type = TTY_DRIVER_TYPE_SYSTEM;
- hvc_driver->init_termios = tty_std_termios;
- hvc_driver->flags = TTY_DRIVER_REAL_RAW;
- tty_set_operations(hvc_driver, &hvc_ops);
+ drv->owner = THIS_MODULE;
+ drv->devfs_name = "hvc/";
+ drv->driver_name = "hvc";
+ drv->name = "hvc";
+ drv->major = HVC_MAJOR;
+ drv->minor_start = HVC_MINOR;
+ drv->type = TTY_DRIVER_TYPE_SYSTEM;
+ drv->init_termios = tty_std_termios;
+ drv->flags = TTY_DRIVER_REAL_RAW;
+ tty_set_operations(drv, &hvc_ops);
/* Always start the kthread because there can be hotplug vty adapters
* added later. */
hvc_task = kthread_run(khvcd, NULL, "khvcd");
if (IS_ERR(hvc_task)) {
panic("Couldn't create kthread for console.\n");
- put_tty_driver(hvc_driver);
+ put_tty_driver(drv);
return -EIO;
}
- if (tty_register_driver(hvc_driver))
+ if (tty_register_driver(drv))
panic("Couldn't register hvc console driver\n");
+ mb();
+ hvc_driver = drv;
return 0;
}
module_init(hvc_init);
^ permalink raw reply
* Re: State of userland headers
From: Kyle Moffett @ 2006-03-25 6:27 UTC (permalink / raw)
To: Rob Landley; +Cc: Nix, Mariusz Mazur, LKML Kernel, llh-discuss
In-Reply-To: <200603242219.54677.rob@landley.net>
On Mar 24, 2006, at 22:19:54, Rob Landley wrote:
> On Friday 24 March 2006 5:46 pm, Kyle Moffett wrote:
>> however. Since the kabi/*.h headers would not be kernel-version-
>> specific, they could be copied to a system running an older kernel
>> and reused there without problems.
>
> Since when is the kernel ABI not kernel version specific? You can
> use an older ABI on a newer kernel, but you can't use a newer ABI
> on an older kernel.
By the very definition of "ABI", it _must_ not be kernel version
specific. A program written for a newer ABI and compiled against it
_must_ be able to gracefully handle syscalls not existing when run on
an older kernel. The program may fail to work entirely because the
syscalls it needs are not present, but that's no different than a
"Kernel does not have feature CONFIG_FOO enabled" issue.
>> Even though some of the syscalls and ioctls referenced in the kabi
>> headers might not be present on the running kernel, portable
>> programs are expected to be able to sanely handle older kernels.
>
> At the source level, maybe. At the binary level? Not really.
The ABI must be compatible at both source and binary interfaces,
"Application _Binary_ Interface" is the name, after all. It's OK to
introduce new features so long as you can gracefully handle them not
being present. Look for example at what happens if I take V4L apps
and run them on a 2.4.0 kernel without V4L. They report that the
kernel is too old or missing features, but aside from V4L not being
present, everything just works.
As a result, I think that if we can clean up the headers in kernel,
we can reuse those same headers for compiling userspace everywhere,
even if the userspace is going to be run on an older kernel.
Cheers,
Kyle Moffett
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.