Re: [RFC] buildtar: add case for riscv architecture
None of the available RiscV platforms that I’m aware of use compressed images, unless there are some new bootloaders I haven’t seen yet. > On Sep 11, 2019, at 2:07 AM, Aurabindo Jayamohanan wrote: > > Hi, > > I would like to know if something extra needs to be done other than copying > compressed kernel image, when making tar package for riscv architecture. > Please see the attached patch. > > -- > > Thanks and Regards, > Aurabindo Jayamohanan > <0001-buildtar-add-riscv-case.patch>___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode
> On Aug 21, 2019, at 4:02 PM, Anup Patel wrote: > > > >> -Original Message- >> From: linux-kernel-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Troy Benjegerdes >> Sent: Wednesday, August 21, 2019 11:25 PM >> To: Atish Patra >> Cc: h...@lst.de; paul.walms...@sifive.com; linux-ri...@lists.infradead.org; >> Damien Le Moal ; linux- >> ker...@vger.kernel.org; pal...@sifive.com >> Subject: Re: [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode >> >> >> >>> On Aug 21, 2019, at 10:31 AM, Atish Patra wrote: >>> >>> On Tue, 2019-08-20 at 21:14 -0700, Troy Benjegerdes wrote: >>>>> On Aug 13, 2019, at 8:47 AM, Christoph Hellwig wrote: >>>>> >>>>> No point in bloating the kernel image with a bootloader header if we >>>>> run bare metal. >>>> >>>> I would say the same for S-mode. EFI booting should be an option, not >>>> a requirement. >>> >>> EFI booting is never a requirement on any board. When EFI stub will be >>> added for kernel, it will be enabled with CONFIG_EFI_STUB only. >>> >>> The current additional header is only 64 bytes and also required for >>> booti in U-boot. So it shouldn't disabled for S-mode. >>> >>> Disabling it for M-Mode Linux is okay because of memory constraint and >>> M-Mode linux won't use U-boot anyways. >>> >>>> I have M-mode U-boot working with bootelf to start BBL, and at some >>>> point, I’m hoping we can have a M-mode linux kernel be the SBI >>>> provider for S-mode kernels, >>> >>> Why do you want bloat a M-Mode software with Linux just for SBI >>> implementation? >>> >>> Using Linux as a last stage boot loader i.e. LinuxBoot may make sense >>> though. >>> >> >> Boot time, and ease of development, and simplified system management. >> >> Having M-mode linux as a supervisor/boot kernel can get us to responding to >> HTTPS/SSH/etc requests within seconds of power-on, while the ‘boot’ >> kernel can be loading guest S-mode kernels from things like NVME flash >> drives that are going to be a lot more code and development to support in U- >> boot or any other non-linux dedicated boot loader. > > I don't see why these things cannot be achieved in existing open-source > bootloaders. In fact, U-boot already has "Falcon" mode for fast booting. > >> >> There’s also a very strong security argument, as Linux is going to get the >> largest and broadest security review, and will likely get software updates a >> lot faster than dedicated boot firmwares will. > > For security, we have to get SW certified with various something like ISO2626 > standard. This is very common practice in Automotive industry. To achieve such > a certification for any SW, the size of code base is very very important. > > Due to this reason, even today Linux (and other big open-source project) > are very difficult to be security certified. There’s security certified, and then there’s what I personally consider secure. The second category is code that I know is widely audited by lots of people, and gets quickly updated when there is a problem. I like U-boot, and I think its a great solution for industry, it’s just not the only solution that could be used. > >> >> Another reason would be sharing the same kernel binary (elf file) for both >> M-mode, and S-mode, and using the device tree passed to each to specify >> which mode it should be running it. There are probably a bunch of gotchas >> with this idea, and even so I suspect someone will decide to go ahead and >> just do it eventually because it could make testing, validation, and security >> updates a lot easier from an operational/deployment point of view. >> >> Linuxbios convinced me that if you want to do a really large cluster, you can >> build, manage, and run such a thing with fewer people and engineering cost >> than if you have all these extra layers of boot firmware that require some >> company to have firmware engineers and lots of extra system testing on the >> firmware. > > I don't by this last argument. These days it's just very few folks doing > firmware, > bootloader, and Linux porting for any new SOC (any architecture). Most of > the things are already there in various open-source project so same person > can easily contribute to various projects. > > Regards, > Anup What I see though is we’re duplicating code and work between bootloaders and kernel, for example the SPI-NOR code, and if it was all linux, it would be one driver model to learn/remember/track, and one place to fix things. U-boot is great because you can boot other !linux things (like FreeBSD), however if I was purpose building a linux cluster, I would want to be running linux as early as possible so I can use linux scripting in bash/go/python and talk to the queue/workload manager over a native high performance network instead of the extremely limited ‘hush’ shell and having to discover which user image to boot with something old and slow like dhcp/tftp/etc.
Re: [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode
> On Aug 21, 2019, at 10:31 AM, Atish Patra wrote: > > On Tue, 2019-08-20 at 21:14 -0700, Troy Benjegerdes wrote: >>> On Aug 13, 2019, at 8:47 AM, Christoph Hellwig wrote: >>> >>> No point in bloating the kernel image with a bootloader header if >>> we run bare metal. >> >> I would say the same for S-mode. EFI booting should be an option, not >> a requirement. > > EFI booting is never a requirement on any board. When EFI stub will be > added for kernel, it will be enabled with CONFIG_EFI_STUB only. > > The current additional header is only 64 bytes and also required for > booti in U-boot. So it shouldn't disabled for S-mode. > > Disabling it for M-Mode Linux is okay because of memory constraint and > M-Mode linux won't use U-boot anyways. > >> I have M-mode U-boot working with bootelf to start BBL, >> and at some point, I’m hoping we can have a M-mode linux kernel be >> the SBI provider for S-mode kernels, > > Why do you want bloat a M-Mode software with Linux just for SBI > implementation? > > Using Linux as a last stage boot loader i.e. LinuxBoot may make sense > though. > Boot time, and ease of development, and simplified system management. Having M-mode linux as a supervisor/boot kernel can get us to responding to HTTPS/SSH/etc requests within seconds of power-on, while the ‘boot’ kernel can be loading guest S-mode kernels from things like NVME flash drives that are going to be a lot more code and development to support in U-boot or any other non-linux dedicated boot loader. There’s also a very strong security argument, as Linux is going to get the largest and broadest security review, and will likely get software updates a lot faster than dedicated boot firmwares will. Another reason would be sharing the same kernel binary (elf file) for both M-mode, and S-mode, and using the device tree passed to each to specify which mode it should be running it. There are probably a bunch of gotchas with this idea, and even so I suspect someone will decide to go ahead and just do it eventually because it could make testing, validation, and security updates a lot easier from an operational/deployment point of view. Linuxbios convinced me that if you want to do a really large cluster, you can build, manage, and run such a thing with fewer people and engineering cost than if you have all these extra layers of boot firmware that require some company to have firmware engineers and lots of extra system testing on the firmware.
Re: [PATCH 15/15] riscv: disable the EFI PECOFF header for M-mode
> On Aug 13, 2019, at 8:47 AM, Christoph Hellwig wrote: > > No point in bloating the kernel image with a bootloader header if > we run bare metal. I would say the same for S-mode. EFI booting should be an option, not a requirement. I have M-mode U-boot working with bootelf to start BBL, and at some point, I’m hoping we can have a M-mode linux kernel be the SBI provider for S-mode kernels, which seem most logical to me to start using the vmlinux elf binaries using something like kexec() > > Signed-off-by: Christoph Hellwig > --- > arch/riscv/kernel/head.S | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S > index 670e5cacb24e..09fcf3d000c0 100644 > --- a/arch/riscv/kernel/head.S > +++ b/arch/riscv/kernel/head.S > @@ -16,6 +16,7 @@ > > __INIT > ENTRY(_start) > +#ifndef CONFIG_M_MODE > /* >* Image header expected by Linux boot-loaders. The image header data >* structure is described in asm/image.h. > @@ -47,6 +48,7 @@ ENTRY(_start) > > .global _start_kernel > _start_kernel: > +#endif /* CONFIG_M_MODE */ > /* Mask all interrupts */ > csrw CSR_XIE, zero > csrw CSR_XIP, zero > -- > 2.20.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH] RISC-V: Issue a local tlb flush if possible.
> On Aug 9, 2019, at 8:43 PM, Atish Patra wrote:
>
> In RISC-V, tlb flush happens via SBI which is expensive.
> If the target cpumask contains a local hartid, some cost
> can be saved by issuing a local tlb flush as we do that
> in OpenSBI anyways.
Is there anything other than convention and current usage that prevents
the kernel from natively handling TLB flushes without ever making the SBI
call?
Someone is eventually going to want to run the linux kernel in machine mode,
likely for performance and/or security reasons, and this will require flushing
TLBs
natively anyway.
>
> Signed-off-by: Atish Patra
> ---
> arch/riscv/include/asm/tlbflush.h | 33 +++
> 1 file changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/include/asm/tlbflush.h
> b/arch/riscv/include/asm/tlbflush.h
> index 687dd19735a7..b32ba4fa5888 100644
> --- a/arch/riscv/include/asm/tlbflush.h
> +++ b/arch/riscv/include/asm/tlbflush.h
> @@ -8,6 +8,7 @@
> #define _ASM_RISCV_TLBFLUSH_H
>
> #include
> +#include
> #include
>
> /*
> @@ -46,14 +47,38 @@ static inline void remote_sfence_vma(struct cpumask
> *cmask, unsigned long start,
>unsigned long size)
> {
> struct cpumask hmask;
> + struct cpumask tmask;
> + int cpuid = smp_processor_id();
>
> cpumask_clear();
> - riscv_cpuid_to_hartid_mask(cmask, );
> - sbi_remote_sfence_vma(hmask.bits, start, size);
> + cpumask_clear();
> +
> + if (cmask)
> + cpumask_copy(, cmask);
> + else
> + cpumask_copy(, cpu_online_mask);
> +
> + if (cpumask_test_cpu(cpuid, )) {
> + /* Save trap cost by issuing a local tlb flush here */
> + if ((start == 0 && size == -1) || (size > PAGE_SIZE))
> + local_flush_tlb_all();
> + else if (size == PAGE_SIZE)
> + local_flush_tlb_page(start);
> + cpumask_clear_cpu(cpuid, );
> + } else if (cpumask_empty()) {
> + /* cpumask is empty. So just do a local flush */
> + local_flush_tlb_all();
> + return;
> + }
> +
> + if (!cpumask_empty()) {
> + riscv_cpuid_to_hartid_mask(, );
> + sbi_remote_sfence_vma(hmask.bits, start, size);
> + }
> }
>
> -#define flush_tlb_all() sbi_remote_sfence_vma(NULL, 0, -1)
> -#define flush_tlb_page(vma, addr) flush_tlb_range(vma, addr, 0)
> +#define flush_tlb_all() remote_sfence_vma(NULL, 0, -1)
> +#define flush_tlb_page(vma, addr) flush_tlb_range(vma, addr, (addr) +
> PAGE_SIZE)
> #define flush_tlb_range(vma, start, end) \
> remote_sfence_vma(mm_cpumask((vma)->vm_mm), start, (end) - (start))
> #define flush_tlb_mm(mm) \
> --
> 2.21.0
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH] RISC-V: defconfig: enable MMC & SPI for RISC-V
> On Jun 25, 2019, at 5:56 PM, Atish Patra wrote: > > Currently, riscv upstream defconfig doesn't let you boot > through userspace if rootfs is on the SD card. > > Let's enable MMC & SPI drivers as well so that one can boot > to the user space using default config in upstream kernel. > > Signed-off-by: Atish Patra > --- > arch/riscv/configs/defconfig | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig > index 4f02967e55de..04944fb4fa7a 100644 > --- a/arch/riscv/configs/defconfig > +++ b/arch/riscv/configs/defconfig > @@ -69,6 +69,7 @@ CONFIG_VIRTIO_MMIO=y > CONFIG_CLK_SIFIVE=y > CONFIG_CLK_SIFIVE_FU540_PRCI=y > CONFIG_SIFIVE_PLIC=y > +CONFIG_SPI_SIFIVE=y > CONFIG_EXT4_FS=y > CONFIG_EXT4_FS_POSIX_ACL=y > CONFIG_AUTOFS4_FS=y > @@ -84,4 +85,8 @@ CONFIG_ROOT_NFS=y > CONFIG_CRYPTO_USER_API_HASH=y > CONFIG_CRYPTO_DEV_VIRTIO=y > CONFIG_PRINTK_TIME=y > +CONFIG_SPI=y > +CONFIG_MMC_SPI=y > +CONFIG_MMC=y > +CONFIG_DEVTMPFS_MOUNT=y > # CONFIG_RCU_TRACE is not set > -- > 2.21.0 While we are doing this, can we add and test the /dev/mtd device? I tried adding the following but I am missing something CONFIG_MTD=y CONFIG_MTD_OF_PARTS=y CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK_RO=y CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y CONFIG_MTD_M25P80=y CONFIG_MTD_SPI_NOR=y CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y and I see this in the log [1.106626] m25p80 spi0.0: unrecognized JEDEC id bytes: 9d 70 19 9d 70 19
Re: [PATCH v2] riscv: dts: Add DT node for SiFive FU540 Ethernet controller driver
> On Jun 21, 2019, at 2:14 PM, Atish Patra wrote:
>
> On Fri, 2019-06-21 at 16:23 +0530, Yash Shah wrote:
>> DT node for SiFive FU540-C000 GEMGXL Ethernet controller driver added
>>
>> Signed-off-by: Yash Shah
>> ---
>> arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 16
>>
>> arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 9 +
>> 2 files changed, 25 insertions(+)
>>
>> diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>> b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>> index 4e8fbde..c53b4ea 100644
>> --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>> +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>> @@ -225,5 +225,21 @@
>> #address-cells = <1>;
>> #size-cells = <0>;
>> };
>> +eth0: ethernet@1009 {
>> +compatible = "sifive,fu540-macb";
>> +interrupt-parent = <>;
>> +interrupts = <53>;
>> +reg = <0x0 0x1009 0x0 0x2000
>> + 0x0 0x100a 0x0 0x1000>;
>> +reg-names = "control";
>> +status = "disabled";
>> +local-mac-address = [00 00 00 00 00 00];
>> +clock-names = "pclk", "hclk";
>> +clocks = < PRCI_CLK_GEMGXLPLL>,
>> + < PRCI_CLK_GEMGXLPLL>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +};
>> +
>> };
>> };
>> diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
>> b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
>> index 4da8870..d783bf2 100644
>> --- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
>> +++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
>> @@ -63,3 +63,12 @@
>> disable-wp;
>> };
>> };
>> +
>> + {
>> +status = "okay";
>> +phy-mode = "gmii";
>> +phy-handle = <>;
>> +phy1: ethernet-phy@0 {
>> +reg = <0>;
>> +};
>> +};
>
> Thanks. I am able to boot Unleashed with networking enabled with this
> patch.
>
> FWIW,
> Tested-by: Atish Patra
>
> Regards,
> Atish
I am able to boot using a build from the dev/new-dts branch of
my freedom-u-sdk development tree [1] which has this patch
with an additional reset-gpios entry for the ethernet phy in the
DTS provided by the legacy U-boot[2].
Tested-by: Troy Benjegerdes
[1] https://github.com/tmagik/freedom-u-sdk
[2]
https://github.com/sifive/HiFive_U-Boot/blob/081373fa3eb0ca79ba3f4a703e8e83a15135a6d1/arch/riscv/dts/hifive_u540.dts#L73
Re: [PATCH v2] riscv: dts: Add DT node for SiFive FU540 Ethernet controller driver
> On Jun 21, 2019, at 7:33 PM, Troy Benjegerdes
> wrote:
>
>
>
>> On Jun 21, 2019, at 4:59 PM, Atish Patra wrote:
>>
>> On Fri, 2019-06-21 at 14:46 -0700, Atish Patra wrote:
>>> On Fri, 2019-06-21 at 14:18 -0500, Troy Benjegerdes wrote:
>>>> Can you post the fsbl and other images you used to boot/test this?
>>>>
>>>
>>
>> Resending it without the attachment. Obviously, the mail did not go
>> through with the binary blob attached :( :(. My bad.
>>
>> Let me know if you still want me to share the binary with you. I will
>> probably share it via some other method.
>
> The bl came through as it was sent direct to me, and I can deal with
> the tftp config manually. I have a kernel image, but not the boot.scr.uimg
> that it looks like you are using. Is that from Yocto?
I got console output, after extracting the boot script from yocto.
The important part seems to be calling
‘bootm $kernel_addr_r - $fdt_addr_r’
Which maybe leads into a discussion of what can we do to at
least output some sort of useful debug information if the device
tree is not found or invalid?
I’d also like to propose that on RiscV, we use the chosen node
for kernel command line and initrd location (like qemu does), and
in u-boot, default to always passing the device tree from bootm
and other commands (like bootelf)
>
>>
>>> I have not changed fsbl. It's the default one came with the board.
>>> Here are the heads of OpenSBI + U-Boot + Linux repo.
>>>
>>> OpenSBI: cd2dfdc870ed (master)
>>> U-boot: 77f6e2dd0551 + Anup's patch series (v4)
>>> https://github.com/atishp04/u-boot/tree/unleashed_working
>>>
>>> Linux: bed3c0d84e7e + Yash's Macb Series + this patch
>>> https://github.com/atishp04/linux/tree/5.2-rc6-pre
>>>
>>> I have also attached the OpenSBI + U-boot binary as well. But this is
>>> pre-configured with my tftpboot server. You need to change that.
>>>
>>>> I keep running into various failures when I build from source and I
>>>> want to rule out potential hardware issues related to clock and/or
>>>> ddr initialization
>>>>
>>>> On Fri, Jun 21, 2019, 2:14 PM Atish Patra
>>>> wrote:
>>>>> On Fri, 2019-06-21 at 16:23 +0530, Yash Shah wrote:
>>>>>> DT node for SiFive FU540-C000 GEMGXL Ethernet controller driver
>>>>> added
>>>>>> Signed-off-by: Yash Shah
>>>>>> ---
>>>>>> arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 16
>>>>>>
>>>>>> arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 9
>>>>> +
>>>>>> 2 files changed, 25 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>>>>>> b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>>>>>> index 4e8fbde..c53b4ea 100644
>>>>>> --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>>>>>> +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>>>>>> @@ -225,5 +225,21 @@
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <0>;
>>>>>> };
>>>>>> + eth0: ethernet@1009 {
>>>>>> + compatible = "sifive,fu540-macb";
>>>>>> + interrupt-parent = <>;
>>>>>> + interrupts = <53>;
>>>>>> + reg = <0x0 0x1009 0x0 0x2000
>>>>>> +0x0 0x100a 0x0 0x1000>;
>>>>>> + reg-names = "control";
>>>>>> + status = "disabled";
>>>>>> + local-mac-address = [00 00 00 00 00 00];
>>>>>> + clock-names = "pclk", "hclk";
>>>>>> + clocks = < PRCI_CLK_GEMGXLPLL>,
>>>>>> + < PRCI_CLK_GEMGXLPLL>;
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + };
>>>>>> +
>>>>>> };
>>>>>> };
>>>>>> diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-
>>>>>> a00.dts
>>>>>> b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
>>>>>> index 4da8870..d783bf2 100644
>>>>>> --- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
>>>>>> +++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
>>>>>> @@ -63,3 +63,12 @@
>>>>>> disable-wp;
>>>>>> };
>>>>>> };
>>>>>> +
>>>>>> + {
>>>>>> + status = "okay";
>>>>>> + phy-mode = "gmii";
>>>>>> + phy-handle = <>;
>>>>>> + phy1: ethernet-phy@0 {
>>>>>> + reg = <0>;
>>>>>> + };
>>>>>> +};
>>>>>
>>>>> Thanks. I am able to boot Unleashed with networking enabled with
>>>>> this
>>>>> patch.
>>>>>
>>>>> FWIW,
>>>>> Tested-by: Atish Patra
>>>>>
>>>>> Regards,
>>>>> Atish
>>>>> ___
>>>>> linux-riscv mailing list
>>>>> linux-ri...@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
Re: [PATCH v2] riscv: dts: Add DT node for SiFive FU540 Ethernet controller driver
> On Jun 21, 2019, at 4:59 PM, Atish Patra wrote:
>
> On Fri, 2019-06-21 at 14:46 -0700, Atish Patra wrote:
>> On Fri, 2019-06-21 at 14:18 -0500, Troy Benjegerdes wrote:
>>> Can you post the fsbl and other images you used to boot/test this?
>>>
>>
>
> Resending it without the attachment. Obviously, the mail did not go
> through with the binary blob attached :( :(. My bad.
>
> Let me know if you still want me to share the binary with you. I will
> probably share it via some other method.
The bl came through as it was sent direct to me, and I can deal with
the tftp config manually. I have a kernel image, but not the boot.scr.uimg
that it looks like you are using. Is that from Yocto?
>
>> I have not changed fsbl. It's the default one came with the board.
>> Here are the heads of OpenSBI + U-Boot + Linux repo.
>>
>> OpenSBI: cd2dfdc870ed (master)
>> U-boot: 77f6e2dd0551 + Anup's patch series (v4)
>> https://github.com/atishp04/u-boot/tree/unleashed_working
>>
>> Linux: bed3c0d84e7e + Yash's Macb Series + this patch
>> https://github.com/atishp04/linux/tree/5.2-rc6-pre
>>
>> I have also attached the OpenSBI + U-boot binary as well. But this is
>> pre-configured with my tftpboot server. You need to change that.
>>
>>> I keep running into various failures when I build from source and I
>>> want to rule out potential hardware issues related to clock and/or
>>> ddr initialization
>>>
>>> On Fri, Jun 21, 2019, 2:14 PM Atish Patra
>>> wrote:
>>>> On Fri, 2019-06-21 at 16:23 +0530, Yash Shah wrote:
>>>>> DT node for SiFive FU540-C000 GEMGXL Ethernet controller driver
>>>> added
>>>>> Signed-off-by: Yash Shah
>>>>> ---
>>>>> arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 16
>>>>>
>>>>> arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 9
>>>> +
>>>>> 2 files changed, 25 insertions(+)
>>>>>
>>>>> diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>>>>> b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>>>>> index 4e8fbde..c53b4ea 100644
>>>>> --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>>>>> +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
>>>>> @@ -225,5 +225,21 @@
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>> };
>>>>> + eth0: ethernet@1009 {
>>>>> + compatible = "sifive,fu540-macb";
>>>>> + interrupt-parent = <>;
>>>>> + interrupts = <53>;
>>>>> + reg = <0x0 0x1009 0x0 0x2000
>>>>> +0x0 0x100a 0x0 0x1000>;
>>>>> + reg-names = "control";
>>>>> + status = "disabled";
>>>>> + local-mac-address = [00 00 00 00 00 00];
>>>>> + clock-names = "pclk", "hclk";
>>>>> + clocks = < PRCI_CLK_GEMGXLPLL>,
>>>>> + < PRCI_CLK_GEMGXLPLL>;
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> + };
>>>>> +
>>>>> };
>>>>> };
>>>>> diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-
>>>>> a00.dts
>>>>> b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
>>>>> index 4da8870..d783bf2 100644
>>>>> --- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
>>>>> +++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
>>>>> @@ -63,3 +63,12 @@
>>>>> disable-wp;
>>>>> };
>>>>> };
>>>>> +
>>>>> + {
>>>>> + status = "okay";
>>>>> + phy-mode = "gmii";
>>>>> + phy-handle = <>;
>>>>> + phy1: ethernet-phy@0 {
>>>>> + reg = <0>;
>>>>> + };
>>>>> +};
>>>>
>>>> Thanks. I am able to boot Unleashed with networking enabled with
>>>> this
>>>> patch.
>>>>
>>>> FWIW,
>>>> Tested-by: Atish Patra
>>>>
>>>> Regards,
>>>> Atish
>>>> ___
>>>> linux-riscv mailing list
>>>> linux-ri...@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v2 0/2] Add macb support for SiFive FU540-C000
> On Jun 18, 2019, at 4:32 AM, Anup Patel wrote: > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72296bde4f4207566872ee355950a59cbc29f852 I added your patches, along with two of mine, and rebased them to the latest U-boot master, and put them on the ‘to-upstream’ branch at https://github.com/sifive/u-boot/tree/to-upstream I am most interested in review of the patch that adds the DTS files from Linux to U-boot, along with a ‘-u-boot.dtsi’ file which includes several extra things, most notably an ethernet entry [1] which does not match the new proposed changes for the MacB driver that Yash is working on. How close are we to consensus on the new “sifive,fu540-macb” device tree entry format? Is this something that is stable enough to start basing some work in M-mode U-boot on yet, or do we expect more changes? [1] https://github.com/sifive/u-boot/commit/35e4168e36139722f30143a0ca0aa8637dd3ee04#diff-27d2d375ddac52f1bca71594075e1be4R93
Re: [PATCH v2 0/2] Add macb support for SiFive FU540-C000
> On Jun 17, 2019, at 6:34 AM, Paul Walmsley wrote: > > On Mon, 17 Jun 2019, Andreas Schwab wrote: > >> On Jun 17 2019, Paul Walmsley wrote: >> >>> On Mon, 17 Jun 2019, Andreas Schwab wrote: >>> On Jun 17 2019, Paul Walmsley wrote: > Looks to me that it shouldn't have an impact unless the DT string is > present, and even then, the impact might simply be that the MACB driver > may not work? If the macb driver doesn't work you have an unusable system, of course. >>> >>> Why? >> >> Because a system is useless without network. > > From an upstream Linux point of view, Yash's patches should be an > improvement over the current mainline kernel situation, since there's > currently no upstream support for the (SiFive-specific) TX clock switch > register. With the right DT data, and a bootloader that handles the PHY > reset, I think networking should work after his patches are upstream -- > although I myself haven't tried this yet. > Have we documented this tx clock switch register in something with a direct URL link (rather than a PDF)? I’d like to update freedom-u-sdk (or yocto) to create bootable images with a working U-boot (upstream or not, I don’t care, as long as it works), and what I have right now is the old legacy HiFive U-boot[1] and a 4.19 kernel with a bunch of extra patches. The legacy M-mode U-boot handles the phy reset already, and I’ve been able to load upstream S-mode uboot as a payload via TFTP, and then load and boot a 4.19 kernel. It would be nice to get this all working with 5.x, however there are still several missing pieces to really have it work well. [1] https://github.com/sifive/HiFive_U-Boot
Re: Testing the recent RISC-V DT patchsets
> On Jun 3, 2019, at 4:49 AM, Loys Ollivier wrote: > > On Wed 29 May 2019 at 12:25, Troy Benjegerdes > wrote: > >>> On May 29, 2019, at 5:04 AM, Loys Ollivier wrote: >>> >>> On Wed 29 May 2019 at 00:50, Atish Patra wrote: >>> >>>> On 5/28/19 8:36 AM, Karsten Merker wrote: >>>>> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote: >>>>>> On Tue 28 May 2019 at 01:32, Paul Walmsley >>>>>> wrote: >>>>>> >>>>>>> An update for those testing RISC-V patches: here's a new branch of >>>>>>> riscv-pk/bbl that doesn't try to read or modify the DT data at all, >>>>>>> which >>>>>>> should be useful until U-Boot settles down. >>>>> [...] >>>>>>> Here is an Linux kernel branch with updated DT data that can be booted >>>>>>> with the above bootloader: >>>>>>> >>>>>>> >>>>>>> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental >>>>>>> >>>>>>> A sample boot log follows, using a 'defconfig' build from that branch. >>>>>> >>>>>> Thanks Paul, I can confirm that it works. >>>>>> >>>>>> Something is still unclear to myself. >>>>>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots. >>>>>> Neither FSBL nor riscv-pk/bbl are modifying the DT. >>>>>> >>>>>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on >>>>>> running /init. >>>>>> >>>>>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot >>>>>> doesn't ? >>>>>> Or maybe it is the other way around - OpenSBI/U-boot does something that >>>>>> extra that should not happen. >>>>> >>>>> Hello, >>>>> >>>>> I don't know which version of OpenSBI you are using, but there is >>>>> a problem with the combination of kernel 5.2-rc1 and OpenSBI >>>>> versions before commit >>>>> >>>>> >>>>> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c >>>>> >>>>> that can result in a hang on executing init, so in case you >>>>> should be using an older OpenSBI build that might be the source >>>>> of the problem that you are experiencing. >>>>> >>>>> Regards, >>>>> Karsten >>>>> >>>> >>>> I verified the updated DT with upstream kernel for the boot flow OpenSBI >>>> + U-Boot + Linux or OpenSBI + Linux. >>>> >>>> OpenSBI should be compiled for sifive platform with following additional >>>> argument >>>> >>>> FW_PAYLOAD_FDT_PATH=>>> source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb >>>> >>>> FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI >>>> directly. >>>> >>> >>> Hum, I am surprised by this statement. >>> I was able to verify the latest DT patch serie from Paul with: >>> OpenSBI + U-Boot + Linux & DT. >>> >>> Following the OpenSBI documentation [0] with U-Boot payload: >>> FW_PAYLOAD_PATH=/u-boot.bin >>> >>> I get an U-Boot prompt and then I can just load the linux kernel and >>> device tree from the network. >>> >>> [0]: >>> https://github.com/riscv/opensbi/blob/master/docs/platform/sifive_fu540.md#building-sifive-fu540-platform >>> >> >> Could you confirm which git hash of U-boot you are building, and that the >> .config matches >> the defconfig (or send me the .config you used)? > > Sure, > > OpenSBI: a6395acd6cb2c35871481d3e4f0beaf449f8c0fd > U-Boot: (origin/master) 344a0e4367d0820b8eb2ea4a90132433e038095f > Kernel: from Paul from this thread [1] > > I use the sifive_fu540_defconfig of U-Boot with no additional changes. > > [1] > https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental > >> >> I’d like to get everything that’s working integrated in one place into a >> freedom-u-sdk test branch. >> >> > > Let me know the test branch when it's up :) > > Loys Please take a look at https://github.com/tmagik/freedom-u-sdk/tree/functional_test When I booted the original 4.19 vmlinux.bin, I got this: Booting kernel in 2 1 0 ## Starting application at 0x8020 ... [0.00] Linux version 4.19.0-sifive-1+ (troyb@epsilon09) (gcc version 8.3.0 (Buildroot 29 [0.00] bootconsole [early0] enabled With the 5.2 kernel, I get know output, which I assume is expected behavior using the current DTS provided by the S-mode Uboot. Booting kernel in 2 1 0 ## Starting application at 0x8020 ...
Re: Testing the recent RISC-V DT patchsets
> On Jun 3, 2019, at 4:49 AM, Loys Ollivier wrote: > > On Wed 29 May 2019 at 12:25, Troy Benjegerdes > wrote: > >>> On May 29, 2019, at 5:04 AM, Loys Ollivier wrote: >>> >>> On Wed 29 May 2019 at 00:50, Atish Patra wrote: >>> >>>> On 5/28/19 8:36 AM, Karsten Merker wrote: >>>>> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote: >>>>>> On Tue 28 May 2019 at 01:32, Paul Walmsley >>>>>> wrote: >>>>>> >>>>>>> An update for those testing RISC-V patches: here's a new branch of >>>>>>> riscv-pk/bbl that doesn't try to read or modify the DT data at all, >>>>>>> which >>>>>>> should be useful until U-Boot settles down. >>>>> [...] >>>>>>> Here is an Linux kernel branch with updated DT data that can be booted >>>>>>> with the above bootloader: >>>>>>> >>>>>>> >>>>>>> https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental >>>>>>> >>>>>>> A sample boot log follows, using a 'defconfig' build from that branch. >>>>>> >>>>>> Thanks Paul, I can confirm that it works. >>>>>> >>>>>> Something is still unclear to myself. >>>>>> Using FSBL + riscv-pk/bbl the linux kernel + device tree boots. >>>>>> Neither FSBL nor riscv-pk/bbl are modifying the DT. >>>>>> >>>>>> Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on >>>>>> running /init. >>>>>> >>>>>> Would you have any pointer on what riscv-pk does that OpenSBI/U-boot >>>>>> doesn't ? >>>>>> Or maybe it is the other way around - OpenSBI/U-boot does something that >>>>>> extra that should not happen. >>>>> >>>>> Hello, >>>>> >>>>> I don't know which version of OpenSBI you are using, but there is >>>>> a problem with the combination of kernel 5.2-rc1 and OpenSBI >>>>> versions before commit >>>>> >>>>> >>>>> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c >>>>> >>>>> that can result in a hang on executing init, so in case you >>>>> should be using an older OpenSBI build that might be the source >>>>> of the problem that you are experiencing. >>>>> >>>>> Regards, >>>>> Karsten >>>>> >>>> >>>> I verified the updated DT with upstream kernel for the boot flow OpenSBI >>>> + U-Boot + Linux or OpenSBI + Linux. >>>> >>>> OpenSBI should be compiled for sifive platform with following additional >>>> argument >>>> >>>> FW_PAYLOAD_FDT_PATH=>>> source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb >>>> >>>> FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI >>>> directly. >>>> >>> >>> Hum, I am surprised by this statement. >>> I was able to verify the latest DT patch serie from Paul with: >>> OpenSBI + U-Boot + Linux & DT. >>> >>> Following the OpenSBI documentation [0] with U-Boot payload: >>> FW_PAYLOAD_PATH=/u-boot.bin >>> >>> I get an U-Boot prompt and then I can just load the linux kernel and >>> device tree from the network. >>> >>> [0]: >>> https://github.com/riscv/opensbi/blob/master/docs/platform/sifive_fu540.md#building-sifive-fu540-platform >>> >> >> Could you confirm which git hash of U-boot you are building, and that the >> .config matches >> the defconfig (or send me the .config you used)? > > Sure, > > OpenSBI: a6395acd6cb2c35871481d3e4f0beaf449f8c0fd > U-Boot: (origin/master) 344a0e4367d0820b8eb2ea4a90132433e038095f > Kernel: from Paul from this thread [1] > > I use the sifive_fu540_defconfig of U-Boot with no additional changes. > > [1] > https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental > >> >> I’d like to get everything that’s working integrated in one place into a >> freedom-u-sdk test branch. >> >> > > Let me know the test branch when it's up :) > > Loys > Have a look at https
Re: Testing the recent RISC-V DT patchsets
> On May 29, 2019, at 5:04 AM, Loys Ollivier wrote: > > On Wed 29 May 2019 at 00:50, Atish Patra wrote: > >> On 5/28/19 8:36 AM, Karsten Merker wrote: >>> On Tue, May 28, 2019 at 05:10:42PM +0200, Loys Ollivier wrote: On Tue 28 May 2019 at 01:32, Paul Walmsley wrote: > An update for those testing RISC-V patches: here's a new branch of > riscv-pk/bbl that doesn't try to read or modify the DT data at all, which > should be useful until U-Boot settles down. >>> [...] > Here is an Linux kernel branch with updated DT data that can be booted > with the above bootloader: > > > https://github.com/sifive/riscv-linux/tree/dev/paulw/dts-v5.2-rc1-experimental > > A sample boot log follows, using a 'defconfig' build from that branch. Thanks Paul, I can confirm that it works. Something is still unclear to myself. Using FSBL + riscv-pk/bbl the linux kernel + device tree boots. Neither FSBL nor riscv-pk/bbl are modifying the DT. Using FSBL + OpenSBI + U-Boot the same kernel + device tree hangs on running /init. Would you have any pointer on what riscv-pk does that OpenSBI/U-boot doesn't ? Or maybe it is the other way around - OpenSBI/U-boot does something that extra that should not happen. >>> >>> Hello, >>> >>> I don't know which version of OpenSBI you are using, but there is >>> a problem with the combination of kernel 5.2-rc1 and OpenSBI >>> versions before commit >>> >>> >>> https://github.com/riscv/opensbi/commit/4e2cd478208531c47343290f15b577d40c82649c >>> >>> that can result in a hang on executing init, so in case you >>> should be using an older OpenSBI build that might be the source >>> of the problem that you are experiencing. >>> >>> Regards, >>> Karsten >>> >> >> I verified the updated DT with upstream kernel for the boot flow OpenSBI >> + U-Boot + Linux or OpenSBI + Linux. >> >> OpenSBI should be compiled for sifive platform with following additional >> argument >> >> FW_PAYLOAD_FDT_PATH=> source>/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb >> >> FYI: It will only work when kernel is given a payload to U-Boot/OpenSBI >> directly. >> > > Hum, I am surprised by this statement. > I was able to verify the latest DT patch serie from Paul with: > OpenSBI + U-Boot + Linux & DT. > > Following the OpenSBI documentation [0] with U-Boot payload: > FW_PAYLOAD_PATH=/u-boot.bin > > I get an U-Boot prompt and then I can just load the linux kernel and > device tree from the network. > > [0]: > https://github.com/riscv/opensbi/blob/master/docs/platform/sifive_fu540.md#building-sifive-fu540-platform > Could you confirm which git hash of U-boot you are building, and that the .config matches the defconfig (or send me the .config you used)? I’d like to get everything that’s working integrated in one place into a freedom-u-sdk test branch. >> Network booting is still not working as the clock driver probe doesn't >> happen because of the updated DT. >> >> -- >> Regards, >> Atish > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Debugging x86_64 apic & bootup problems on the Cray XD1
I am attempting to make a 2.6.20 kernel boot on a Cray XD1 node with a Mellanox InfiniBand card installed, however both the ancient supplied cray 2.6.5 suse derivative, and a 2.6.20 kernel I just booted fail on APIC initialization. Below is a diff of boot-up logs from a node without the mellanox IB card, and one with.. Does anyone have some pointers on debug options I should start turning on? Is there some way I can disable some of the memory regions in the infiniband card via some early PCI init code before APIC's are set up? Processor #0 (Bootup-CPU) Processor #1 I/O APIC #8 at 0xFEC0. - I/O APIC #11 at 0xFDC00100.<- with IB card, misses APIC 9 & 10 - I/O APIC #12 at 0xFE400100. + I/O APIC #9 at 0xF890. + I/O APIC #10 at 0xF8901000. + I/O APIC #11 at 0xF9400100. + I/O APIC #12 at 0xF9C00100. Setting APIC routing to flat Processors: 2 Nosave address range: 0009f000 - 000a Nosave address range: 000a - 0010 Nosave address range: 0070 - 00c0 Allocating PCI resources starting at 8800 (gap: 8000:8000) PERCPU: Allocating 33216 bytes of per cpu data Built 2 zonelists. Total pages: 515735 Kernel command line: root=/dev/nfs nfsroot=10.128.28.6:/var/opt/p ce/nodewc/test1/448.5/root,rsize=1500,wsize=1500 rw no-scroll console=ttyS0,1152 00 amroot=5 hdb=non e hdc=none hdd=none noacpi ide_setup: hdb=none ide_setup: hdc=none ide_setup: hdd=none @@ -55,101 +65,12 @@ CPU 0: aperture @ 8000 size 2048 MB Aperture beyond 4GB. Ignoring. No AGP bridge found Memory: 2054720k/2097152k available (2617k kernel code, 36924k re served, 1287k data, 328k init) Calibrating delay using timer specific routine.. 4391.46 BogoMIPS (lpj=8782926) Security Framework v1.0.0 initialized Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 0/0 -> Node 0 Freeing SMP alternatives: 32k freed <- with IB card, hangs here - Using local APIC timer interrupts. <- without IB card, continues - 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/
Debugging x86_64 apic bootup problems on the Cray XD1
I am attempting to make a 2.6.20 kernel boot on a Cray XD1 node with a Mellanox InfiniBand card installed, however both the ancient supplied cray 2.6.5 suse derivative, and a 2.6.20 kernel I just booted fail on APIC initialization. Below is a diff of boot-up logs from a node without the mellanox IB card, and one with.. Does anyone have some pointers on debug options I should start turning on? Is there some way I can disable some of the memory regions in the infiniband card via some early PCI init code before APIC's are set up? Processor #0 (Bootup-CPU) Processor #1 I/O APIC #8 at 0xFEC0. - I/O APIC #11 at 0xFDC00100.- with IB card, misses APIC 9 10 - I/O APIC #12 at 0xFE400100. + I/O APIC #9 at 0xF890. + I/O APIC #10 at 0xF8901000. + I/O APIC #11 at 0xF9400100. + I/O APIC #12 at 0xF9C00100. Setting APIC routing to flat Processors: 2 Nosave address range: 0009f000 - 000a Nosave address range: 000a - 0010 Nosave address range: 0070 - 00c0 Allocating PCI resources starting at 8800 (gap: 8000:8000) PERCPU: Allocating 33216 bytes of per cpu data Built 2 zonelists. Total pages: 515735 Kernel command line: root=/dev/nfs nfsroot=10.128.28.6:/var/opt/p ce/nodewc/test1/448.5/root,rsize=1500,wsize=1500 rw no-scroll console=ttyS0,1152 00 amroot=5 hdb=non e hdc=none hdd=none noacpi ide_setup: hdb=none ide_setup: hdc=none ide_setup: hdd=none @@ -55,101 +65,12 @@ CPU 0: aperture @ 8000 size 2048 MB Aperture beyond 4GB. Ignoring. No AGP bridge found Memory: 2054720k/2097152k available (2617k kernel code, 36924k re served, 1287k data, 328k init) Calibrating delay using timer specific routine.. 4391.46 BogoMIPS (lpj=8782926) Security Framework v1.0.0 initialized Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 0/0 - Node 0 Freeing SMP alternatives: 32k freed - with IB card, hangs here - Using local APIC timer interrupts. - without IB card, continues - 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: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
On Mon, Apr 18, 2005 at 10:07:12PM +0200, Bernhard Fischer wrote: > On Mon, Apr 18, 2005 at 09:40:40PM +0200, Arjan van de Ven wrote: > >On Mon, 2005-04-18 at 11:25 -0500, Timur Tabi wrote: > >> Arjan van de Ven wrote: > >> > >> > this is a myth; linux is free to move the page about in physical memory > >> > even if it's mlock()ed!! > darn, yes, this is true. > I know people who introduced > #define VM_RESERVED 0x0008 /* Don't unmap it from swap_out > */ Someone (aka Tospin, infinicon, and Amasso) should probably post a patch adding '#define VM_REGISTERD 0x0100', and some extensions to something like 'madvise' to set pages to be registered. My preference is said patch will also allow a way for the kernel to reclaim registered memory from an application under memory pressure. - 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: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
On Mon, Apr 18, 2005 at 10:07:12PM +0200, Bernhard Fischer wrote: On Mon, Apr 18, 2005 at 09:40:40PM +0200, Arjan van de Ven wrote: On Mon, 2005-04-18 at 11:25 -0500, Timur Tabi wrote: Arjan van de Ven wrote: this is a myth; linux is free to move the page about in physical memory even if it's mlock()ed!! darn, yes, this is true. I know people who introduced #define VM_RESERVED 0x0008 /* Don't unmap it from swap_out */ Someone (aka Tospin, infinicon, and Amasso) should probably post a patch adding '#define VM_REGISTERD 0x0100', and some extensions to something like 'madvise' to set pages to be registered. My preference is said patch will also allow a way for the kernel to reclaim registered memory from an application under memory pressure. - 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][0/4] InfiniBand userspace verbs implementation
On Mon, Apr 11, 2005 at 09:56:53AM -0700, Roland Dreier wrote: > Troy> Is there a check in the kernel that the memory is actually > Troy> mlock()ed? > > No. > > Troy> What if a malicious (or broken) application does > Troy> ibv_reg_mr() but doesn't lock the memory? Does the IB card > Troy> get a physical address for a page that might get swapped > Troy> out? > > No, the kernel does get_user_pages(). So the pages that the HCA gets > will not be swapped or used for anything else. The only thing a > malicious userspace app can do is screw itself up. > > - R. Do we even need the mlock in userspace then? - 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][0/4] InfiniBand userspace verbs implementation
On Mon, Apr 11, 2005 at 08:34:19AM -0700, Roland Dreier wrote: > Troy> How is memory pinning handled? (I haven't had time to read > Troy> all the code, so please excuse my ignorance of something > Troy> obvious). > > The userspace library calls mlock() and then the kernel does > get_user_pages(). Is there a check in the kernel that the memory is actually mlock()ed? What if a malicious (or broken) application does ibv_reg_mr() but doesn't lock the memory? Does the IB card get a physical address for a page that might get swapped out? > Troy> The old mellanox drivers used to have a hack to call > Troy> 'sys_mlock', and promiscuously lock memory any old userspace > Troy> application asked for. What is the API for the new uverbs > Troy> memory registration, and how will things like memory hotplug > Troy> and NUMA page migration be able to unpin pages locked by a > Troy> user program? > > The API for uverbs memory registration is ibv_reg_mr(), and right now > the memory is pinned and that's it. > > - 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: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
> In particular, the memory pinning code in in uverbs_mem.c could stand > a looking over. In addition, a sanity check of the write()-based > scheme for passing commands into the kernel in uverbs_main.c and > uverbs_cmd.c is probably worthwhile. How is memory pinning handled? (I haven't had time to read all the code, so please excuse my ignorance of something obvious). The old mellanox drivers used to have a hack to call 'sys_mlock', and promiscuously lock memory any old userspace application asked for. What is the API for the new uverbs memory registration, and how will things like memory hotplug and NUMA page migration be able to unpin pages locked by a user program? I have applications that would benefit from being able to register 15GB of memory on a machine with 16GB. Right now, MPI and other possible users of infiniband in userspace have to play cacheing games and limit what they can register. But locking all that memory without providing the kernel a way to unlock it under memory pressure or for page migration seems like a bad idea. - 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][0/4] InfiniBand userspace verbs implementation
In particular, the memory pinning code in in uverbs_mem.c could stand a looking over. In addition, a sanity check of the write()-based scheme for passing commands into the kernel in uverbs_main.c and uverbs_cmd.c is probably worthwhile. How is memory pinning handled? (I haven't had time to read all the code, so please excuse my ignorance of something obvious). The old mellanox drivers used to have a hack to call 'sys_mlock', and promiscuously lock memory any old userspace application asked for. What is the API for the new uverbs memory registration, and how will things like memory hotplug and NUMA page migration be able to unpin pages locked by a user program? I have applications that would benefit from being able to register 15GB of memory on a machine with 16GB. Right now, MPI and other possible users of infiniband in userspace have to play cacheing games and limit what they can register. But locking all that memory without providing the kernel a way to unlock it under memory pressure or for page migration seems like a bad idea. - 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][0/4] InfiniBand userspace verbs implementation
On Mon, Apr 11, 2005 at 08:34:19AM -0700, Roland Dreier wrote: Troy How is memory pinning handled? (I haven't had time to read Troy all the code, so please excuse my ignorance of something Troy obvious). The userspace library calls mlock() and then the kernel does get_user_pages(). Is there a check in the kernel that the memory is actually mlock()ed? What if a malicious (or broken) application does ibv_reg_mr() but doesn't lock the memory? Does the IB card get a physical address for a page that might get swapped out? Troy The old mellanox drivers used to have a hack to call Troy 'sys_mlock', and promiscuously lock memory any old userspace Troy application asked for. What is the API for the new uverbs Troy memory registration, and how will things like memory hotplug Troy and NUMA page migration be able to unpin pages locked by a Troy user program? The API for uverbs memory registration is ibv_reg_mr(), and right now the memory is pinned and that's it. - 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: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
On Mon, Apr 11, 2005 at 09:56:53AM -0700, Roland Dreier wrote: Troy Is there a check in the kernel that the memory is actually Troy mlock()ed? No. Troy What if a malicious (or broken) application does Troy ibv_reg_mr() but doesn't lock the memory? Does the IB card Troy get a physical address for a page that might get swapped Troy out? No, the kernel does get_user_pages(). So the pages that the HCA gets will not be swapped or used for anything else. The only thing a malicious userspace app can do is screw itself up. - R. Do we even need the mlock in userspace then? - 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 SCM saga..
On Thu, Apr 07, 2005 at 02:29:24PM -0400, Daniel Phillips wrote: > On Thursday 07 April 2005 14:13, Dmitry Yusupov wrote: > > On Thu, 2005-04-07 at 13:54 -0400, Daniel Phillips wrote: > > > Three years ago, there was no fully working open source distributed scm > > > code base to use as a starting point, so extending BK would have been the > > > only easy alternative. But since then the situation has changed. There > > > are now several working code bases to provide a good starting point: > > > Monotone, Arch, SVK, Bazaar-ng and others. > > > > Right. For example, SVK is pretty mature project and very close to 1.0 > > release now. And it supports all kind of merges including Cherry-Picking > > Mergeback: > > > > http://svk.elixus.org/?MergeFeatures > > So for an interim way to get the patch flow back online, SVK is ready to try > _now_, and we only need a way to import the version graph? (true/false) Well, I followed some of the instructions to mirror the kernel tree on svn.clkao.org/linux/cvs, and although it took around 12 hours to import 28232 versions, I seem to have a mirror of it on my own subversion server now. I think the svn.clkao.org mirror was taken from bkcvs... the last log message I see is "Rev 28232 - torvalds - 2005-04-04 09:08:33" I have no idea what's missing. What is everyone's favorite web frontend to subversion? I've got websvn (debian package) on there now, and it's a bit sluggish, but it seems to work. I hope to have time this week or next to actually make this machine publicly accessible. - 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 SCM saga..
On Thu, Apr 07, 2005 at 02:29:24PM -0400, Daniel Phillips wrote: On Thursday 07 April 2005 14:13, Dmitry Yusupov wrote: On Thu, 2005-04-07 at 13:54 -0400, Daniel Phillips wrote: Three years ago, there was no fully working open source distributed scm code base to use as a starting point, so extending BK would have been the only easy alternative. But since then the situation has changed. There are now several working code bases to provide a good starting point: Monotone, Arch, SVK, Bazaar-ng and others. Right. For example, SVK is pretty mature project and very close to 1.0 release now. And it supports all kind of merges including Cherry-Picking Mergeback: http://svk.elixus.org/?MergeFeatures So for an interim way to get the patch flow back online, SVK is ready to try _now_, and we only need a way to import the version graph? (true/false) Well, I followed some of the instructions to mirror the kernel tree on svn.clkao.org/linux/cvs, and although it took around 12 hours to import 28232 versions, I seem to have a mirror of it on my own subversion server now. I think the svn.clkao.org mirror was taken from bkcvs... the last log message I see is Rev 28232 - torvalds - 2005-04-04 09:08:33 I have no idea what's missing. What is everyone's favorite web frontend to subversion? I've got websvn (debian package) on there now, and it's a bit sluggish, but it seems to work. I hope to have time this week or next to actually make this machine publicly accessible. - 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: Cosmetic JFFS patch.
> Let's make it policy that we _never_ print out annoying messages that have > no useful purpose for debugging or running the system, ok? > > "Informational" messages aren't informational, they're just annoying, and > they hide the _real_ stuff. Sometimes, but I've run into WAY too many occasions where all I know about why this sytem died was "what was the last annoying informational boot message". This gets really usefull when you have either old crufty hardware that's questionable OR fresh alpha silicon for some new whizz-bang processor. > Things like version strings etc sound useful, but the fact is that the > only _real_ problem it has ever solved for anybody is when somebody thinks > they install a new kernel, and forgets to run "lilo" or something. But > even that information you really get from a simple "uname -a". > > Do we care that when you boot kernel-2.4.5 you get "net-3"? No. Do we care > that we have quota version "dquot_6.4.0"? No. Do we want to get the > version printed for every single driver we load? No. > > If people care about version printing, it (a) only makes sense for modules > and (b) should therefore maybe be done by the module loader. And modules > already have the MODULE_DESCRIPTION() thing, so they should NOT printk it > on their own. modprobe can do it if it wants to. > > So let's simply disallow versions, author information, and "good status" > messages, ok? For stuff that is useful for debugging (but that the driver > doesn't _know_ is needed), use KERN_DEBUG, so that it doesn't actually end > up printed on the screen normally. > > Authors willing to start sending me patches? > > Linus > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 09:39:15AM +0100, Laramie Leavitt wrote: > > On Wed, Jun 27, 2001 at 01:50:28PM -0700, Linus Torvalds wrote: > > > How about we drop the "printk" altogether, and make it all a comment? > > > > Can we please also drop annoying static informational printk's? > > > > > Linux NET4.0 for Linux 2.4 > > > Based upon Swansea University Computer Society NET3.039 > > > > The later line is not something of interest to most people, and if it > > happens to be they can research it rather than being force-fed history > > on bootup. > > > > > POSIX conformance testing by UNIFIX > > > > Ditto. > > > > > usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, > > Roman Weissgaerber > > > usb-uhci.c: USB Universal Host Controller Interface driver > > > > How about "usb-uhci.c: USB Universal Host Controller Interface > > driver v1.251" > > instead? > > > > dmesg buffer space is rather limited and IMHO there isn't space to > > waste on credit-giving in boot logs. > > Here here. You don't see annoying log-eating copyright messages > printed out in the Windows boot. Just imagine: Whoaa, back the truck up you just threw all those log messages in. One of the reasons I absolutely HATED windoze was that it didn't tell you ANYTHING about what it was doing when booting. If it died during bootup you had no idea what driver was loading. Yes, *some* of the boot messageses are excessive, but I don't know how many times I've been able to diagnose a hardware problem or been helped by verbose boot messages on some strange hardware I was trying to bring up, and the 'what was the last message printed out' has been invaluable. > Initializing VGA Display. VGA Display by John Smith, John Smith, Jr. > Bill T. Gates, Paul G. Allen, Janet K. Reno. Copyright(c) 1985 Microsoft. > Loading Microsoft ATAPI. Microsoft ATAPI Copyright (c) 1983-2001 Microsoft. > Scanning Microsoft SCSI Layer. Portions Copyright (c) 1992 Harold Potter. > Microsoft SCSI Layer developed in part by Seagate Corporation. > Starting Microsoft Display Device. Display based on Microsoft VESA > Extensions. > Display layer Copyright(c) 1983-2001 Microsoft. > Loading Creative Diamond Viper V770 Display Driver. > Diamond Viper V770 Display driver Copyright(c) 1999 Diamond Multimedia. > Diamond Viper V770 Display driver based on NVIDIA TNT2 Display Driver. > NVIDIA TNT2 Copyright(c) 1998-1999 NVIDIA Corporation. > Scanning Network Devices... > WinSock 2000. Copyright(c) 1990-2001 Microsoft. > WinSock 2000 Contributors include: John Doe, Jane Doe, Ed Smith, Herman > Melville. > Starting WinsockDirect. Winsock Direct Copyright(c) 1999 Microsoft. > WinsockDirect supported by 3COM Corporation, Intel Corporation. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 09:39:15AM +0100, Laramie Leavitt wrote: On Wed, Jun 27, 2001 at 01:50:28PM -0700, Linus Torvalds wrote: How about we drop the printk altogether, and make it all a comment? Can we please also drop annoying static informational printk's? Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 The later line is not something of interest to most people, and if it happens to be they can research it rather than being force-fed history on bootup. POSIX conformance testing by UNIFIX Ditto. usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber usb-uhci.c: USB Universal Host Controller Interface driver How about usb-uhci.c: USB Universal Host Controller Interface driver v1.251 instead? dmesg buffer space is rather limited and IMHO there isn't space to waste on credit-giving in boot logs. Here here. You don't see annoying log-eating copyright messages printed out in the Windows boot. Just imagine: Whoaa, back the truck up you just threw all those log messages in. One of the reasons I absolutely HATED windoze was that it didn't tell you ANYTHING about what it was doing when booting. If it died during bootup you had no idea what driver was loading. Yes, *some* of the boot messageses are excessive, but I don't know how many times I've been able to diagnose a hardware problem or been helped by verbose boot messages on some strange hardware I was trying to bring up, and the 'what was the last message printed out' has been invaluable. Initializing VGA Display. VGA Display by John Smith, John Smith, Jr. Bill T. Gates, Paul G. Allen, Janet K. Reno. Copyright(c) 1985 Microsoft. Loading Microsoft ATAPI. Microsoft ATAPI Copyright (c) 1983-2001 Microsoft. Scanning Microsoft SCSI Layer. Portions Copyright (c) 1992 Harold Potter. Microsoft SCSI Layer developed in part by Seagate Corporation. Starting Microsoft Display Device. Display based on Microsoft VESA Extensions. Display layer Copyright(c) 1983-2001 Microsoft. Loading Creative Diamond Viper V770 Display Driver. Diamond Viper V770 Display driver Copyright(c) 1999 Diamond Multimedia. Diamond Viper V770 Display driver based on NVIDIA TNT2 Display Driver. NVIDIA TNT2 Copyright(c) 1998-1999 NVIDIA Corporation. Scanning Network Devices... WinSock 2000. Copyright(c) 1990-2001 Microsoft. WinSock 2000 Contributors include: John Doe, Jane Doe, Ed Smith, Herman Melville. Starting WinsockDirect. Winsock Direct Copyright(c) 1999 Microsoft. WinsockDirect supported by 3COM Corporation, Intel Corporation. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -If this message isn't misspelled, I didn't write it -- Me - Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shulz - 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: Cosmetic JFFS patch.
snip Let's make it policy that we _never_ print out annoying messages that have no useful purpose for debugging or running the system, ok? Informational messages aren't informational, they're just annoying, and they hide the _real_ stuff. Sometimes, but I've run into WAY too many occasions where all I know about why this sytem died was what was the last annoying informational boot message. This gets really usefull when you have either old crufty hardware that's questionable OR fresh alpha silicon for some new whizz-bang processor. Things like version strings etc sound useful, but the fact is that the only _real_ problem it has ever solved for anybody is when somebody thinks they install a new kernel, and forgets to run lilo or something. But even that information you really get from a simple uname -a. Do we care that when you boot kernel-2.4.5 you get net-3? No. Do we care that we have quota version dquot_6.4.0? No. Do we want to get the version printed for every single driver we load? No. If people care about version printing, it (a) only makes sense for modules and (b) should therefore maybe be done by the module loader. And modules already have the MODULE_DESCRIPTION() thing, so they should NOT printk it on their own. modprobe can do it if it wants to. So let's simply disallow versions, author information, and good status messages, ok? For stuff that is useful for debugging (but that the driver doesn't _know_ is needed), use KERN_DEBUG, so that it doesn't actually end up printed on the screen normally. Authors willing to start sending me patches? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -If this message isn't misspelled, I didn't write it -- Me - Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shulz - 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: spindown
On Thu, Jun 21, 2001 at 06:07:01PM +0200, Jamie Lokier wrote: > Pavel Machek wrote: > > > Isn't this why noflushd exists or is this an evil thing that shouldn't > > > ever be used and will eventually eat my disks for breakfast? > > > > It would eat your flash for breakfast. You know, flash memories have > > no spinning parts, so there's nothing to spin down. > > Btw Pavel, does noflushd work with 2.4.4? The noflushd version 2.4 I > tried said it couldn't find some kernel process (kflushd? I don't > remember) and that I should use bdflush. The manual says that's > appropriate for older kernels, but not 2.4.4 surely. Yes, noflushd works with 2.4.x. I'm running it on an ibook with debian-unstable. And as a word of warning: while running noflushd, make sure you 'sync' a few times after an 'apt-get dist-upgrade' that upgrades damn near everything before doing something that crashes the kernel. This WILL eat your ext2fs for breakfast. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: The Joy of Forking
On Mon, Jun 25, 2001 at 04:03:54AM -0400, Rick Hohensee wrote: > > > rtlinux by default > > > no SMP > > > SMP doesn't scale. If this fork comes, the smart maintainer > > > will take the non-SMP fork. > > > > Depends on platform and bus. From reports, it seems to scale just fine on > > non-intel systems. > > Big expensive systems. Non-desktop systems. Non-end-user systems. And > clustering will eat its lunch eventually anyway. You don't get much more end-user than a $2500 Dual Processor Mac G4. (And as soon as you say $2500 is a lot of money, I can probably find a dual CPU PentiumIII system for < $1000) We would be perfectly happy if you have the time and ability to maintain a fork that can do all of this, and those of us that have more than one CPU type will be perfectly happy to ignore it. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: The Joy of Forking
On Mon, Jun 25, 2001 at 04:03:54AM -0400, Rick Hohensee wrote: rtlinux by default no SMP SMP doesn't scale. If this fork comes, the smart maintainer will take the non-SMP fork. Depends on platform and bus. From reports, it seems to scale just fine on non-intel systems. Big expensive systems. Non-desktop systems. Non-end-user systems. And clustering will eat its lunch eventually anyway. You don't get much more end-user than a $2500 Dual Processor Mac G4. (And as soon as you say $2500 is a lot of money, I can probably find a dual CPU PentiumIII system for $1000) We would be perfectly happy if you have the time and ability to maintain a fork that can do all of this, and those of us that have more than one CPU type will be perfectly happy to ignore it. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -If this message isn't misspelled, I didn't write it -- Me - Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shulz - 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: spindown
On Thu, Jun 21, 2001 at 06:07:01PM +0200, Jamie Lokier wrote: Pavel Machek wrote: Isn't this why noflushd exists or is this an evil thing that shouldn't ever be used and will eventually eat my disks for breakfast? It would eat your flash for breakfast. You know, flash memories have no spinning parts, so there's nothing to spin down. Btw Pavel, does noflushd work with 2.4.4? The noflushd version 2.4 I tried said it couldn't find some kernel process (kflushd? I don't remember) and that I should use bdflush. The manual says that's appropriate for older kernels, but not 2.4.4 surely. Yes, noflushd works with 2.4.x. I'm running it on an ibook with debian-unstable. And as a word of warning: while running noflushd, make sure you 'sync' a few times after an 'apt-get dist-upgrade' that upgrades damn near everything before doing something that crashes the kernel. This WILL eat your ext2fs for breakfast. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -If this message isn't misspelled, I didn't write it -- Me - Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shulz - 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: IBM PPC 405 series little endian?
On Mon, Jun 11, 2001 at 03:08:26PM -0400, Mark Salisbury wrote: > On Mon, 11 Jun 2001, Troy Benjegerdes wrote: > > On Mon, Jun 11, 2001 at 01:34:21PM +0200, Zehetbauer Thomas wrote: > > > Has someone experimented with running linux in little-endian mode on IBM > > > PowerPC 405 (Walnut) yet? > > > > With the possible exception of the matrox guy, I haven't heard of ANYONE > > running in LE mode on ppc. The second problem is going to be to recompile > > ALL the applications you want and hope they work. > > actually, we run ppc 603, 750 and 74xx series ppc's little endian in a PCI > based shared memory multicomputer. What I should have said was 'anyone running Linux in LE mode on ppc'. But that's also very interesting that you're running mcos in LE mode. I'm really curious as to why.. because PCI is little endian maybe? Thanks. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: IBM PPC 405 series little endian?
On Mon, Jun 11, 2001 at 01:34:21PM +0200, Zehetbauer Thomas wrote: > Has someone experimented with running linux in little-endian mode on IBM > PowerPC 405 (Walnut) yet? Well, first, I have to ask, why?? First, if you need to deal with little endian data, on a PPC stwbrx & lwbrx are your friends. With the possible exception of the matrox guy, I haven't heard of ANYONE running in LE mode on ppc. The second problem is going to be to recompile ALL the applications you want and hope they work. Finally, if you're doing anything that connects to the internet, remember that network byte order is big-endian. You might find it interesting that even Intel is now re-discovering the usefullness of big-endian in some of their strongarm/Xscale processors. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: IBM PPC 405 series little endian?
On Mon, Jun 11, 2001 at 01:34:21PM +0200, Zehetbauer Thomas wrote: Has someone experimented with running linux in little-endian mode on IBM PowerPC 405 (Walnut) yet? Well, first, I have to ask, why?? First, if you need to deal with little endian data, on a PPC stwbrx lwbrx are your friends. With the possible exception of the matrox guy, I haven't heard of ANYONE running in LE mode on ppc. The second problem is going to be to recompile ALL the applications you want and hope they work. Finally, if you're doing anything that connects to the internet, remember that network byte order is big-endian. You might find it interesting that even Intel is now re-discovering the usefullness of big-endian in some of their strongarm/Xscale processors. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -If this message isn't misspelled, I didn't write it -- Me - Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shulz - 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: IBM PPC 405 series little endian?
On Mon, Jun 11, 2001 at 03:08:26PM -0400, Mark Salisbury wrote: On Mon, 11 Jun 2001, Troy Benjegerdes wrote: On Mon, Jun 11, 2001 at 01:34:21PM +0200, Zehetbauer Thomas wrote: Has someone experimented with running linux in little-endian mode on IBM PowerPC 405 (Walnut) yet? With the possible exception of the matrox guy, I haven't heard of ANYONE running in LE mode on ppc. The second problem is going to be to recompile ALL the applications you want and hope they work. actually, we run ppc 603, 750 and 74xx series ppc's little endian in a PCI based shared memory multicomputer. What I should have said was 'anyone running Linux in LE mode on ppc'. But that's also very interesting that you're running mcos in LE mode. I'm really curious as to why.. because PCI is little endian maybe? Thanks. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -If this message isn't misspelled, I didn't write it -- Me - Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shulz - 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: An improved natsemi driver for 2.2
On Wed, Apr 18, 2001 at 01:48:40PM -0700, Torrey Hoffman wrote: > > This version of the natsemi driver is being successfully used by us (Myrio > Corporation) on hardware that has the 83815 chip on the motherboard, with > the 2.2.17 kernel. It appears to work well with both multicast and unicast, > with decent throughput. It requires the "pci-scan" module by Donald Becker > at scyld.com. > > We would be very interested in any feedback on problems with 2.2.17 or > 2.2.19, and our hope is that some experienced kernel developers will examine > it and alert us of potential problems we haven't tripped over yet. Well, on kernel 2.2.19 on a 'regular' PC box (celeron 533), it works better than the 1.07b version from scyld.com, but it still gets tripped up pretty bad by nfs traffic. (Have you tried NFS on your board at all?). It seems to be acting a lot like the 2.4 driver does. (it seems to at least recover from the error, whereas the scyld.com natsemi.c would appear to not transmit any packets at all after having trouble). I'm getting errors in RX packets.. RX packets:1959 errors:111 dropped:0 overruns:0 frame:305 TX packets:2275 errors:1 dropped:0 overruns:1 carrier:1 If anyone wants the dmesg output of this problem when running with 'debug=7', please let me know. > Most of the code in this driver is by Donald Becker, of course. However, the > driver from scyld.com could not receive packets on our hardware. We started > from the modified version posted by Jocelyn Mayer. That one sort of worked > for us but had problems. Our version backed out some of those changes, and > has fixes for CRC calculation, reading the MAC address from the EEPROM, and > other things. > > I (Torrey Hoffman) am not the developer of our version, although I did go > through it and clean it up a little. I am the alleged "Linux expert" here, > and if there are problems with the driver I am the person to contact. > > I'm cc'ing everyone on my "natsemi" address list, please trim followups. > I do read the mailing list, but please cc me if responding. > > Thanks. > > Torrey Hoffman > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: An improved natsemi driver for 2.2
On Wed, Apr 18, 2001 at 01:48:40PM -0700, Torrey Hoffman wrote: This version of the natsemi driver is being successfully used by us (Myrio Corporation) on hardware that has the 83815 chip on the motherboard, with the 2.2.17 kernel. It appears to work well with both multicast and unicast, with decent throughput. It requires the "pci-scan" module by Donald Becker at scyld.com. We would be very interested in any feedback on problems with 2.2.17 or 2.2.19, and our hope is that some experienced kernel developers will examine it and alert us of potential problems we haven't tripped over yet. Well, on kernel 2.2.19 on a 'regular' PC box (celeron 533), it works better than the 1.07b version from scyld.com, but it still gets tripped up pretty bad by nfs traffic. (Have you tried NFS on your board at all?). It seems to be acting a lot like the 2.4 driver does. (it seems to at least recover from the error, whereas the scyld.com natsemi.c would appear to not transmit any packets at all after having trouble). I'm getting errors in RX packets.. RX packets:1959 errors:111 dropped:0 overruns:0 frame:305 TX packets:2275 errors:1 dropped:0 overruns:1 carrier:1 If anyone wants the dmesg output of this problem when running with 'debug=7', please let me know. Most of the code in this driver is by Donald Becker, of course. However, the driver from scyld.com could not receive packets on our hardware. We started from the modified version posted by Jocelyn Mayer. That one sort of worked for us but had problems. Our version backed out some of those changes, and has fixes for CRC calculation, reading the MAC address from the EEPROM, and other things. I (Torrey Hoffman) am not the developer of our version, although I did go through it and clean it up a little. I am the alleged "Linux expert" here, and if there are problems with the driver I am the person to contact. I'm cc'ing everyone on my "natsemi" address list, please trim followups. I do read the mailing list, but please cc me if responding. Thanks. Torrey Hoffman [EMAIL PROTECTED] [EMAIL PROTECTED] -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: bug in natsemi driver 1.07 for linux 2.4.2
On Fri, Mar 30, 2001 at 07:04:29AM +0200, Sebastian Klemke wrote: > Hi! > > The driver for the natsemi NIC does not properly filter out requested > multicast groups when in multicast mode. Multicast groups I joined > are simply dropped by the MAC address filter of the card, the kernel > filters them correctly in allmulti or promiscuous mode. I've tested > driver versions 1.05 which comes with linux 2.4.2, an older version > that came with linux-2.4.0test12 and 1.07 which came with 2.4.2-ac20. > > I contacted Donald Becker and he told me to post it here. Have you tried Donald Becker's version of the driver under linux 2.2.x? The only natsemi driver I've ever had come close to working is in 2.4.4pre1, and even then it's got some problems that cause poor perfomance, nfs timeouts, and dropped connections with the squid http proxy. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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/
natsemi.c still broken...
On Wed, Apr 11, 2001 at 09:32:36PM -0500, Troy Benjegerdes wrote: > On Wed, Mar 28, 2001 at 12:58:57PM -0500, Jeff Garzik wrote: > > There are some improvements in the latest 2.4 test patch, 2.4.3-pre8. I > > would be very interested in hearing feedback on that. I finally got two > > test cards, FA311 and FA312, so I can work on it a bit too. > > Okay, I finally got around to testing this on 2.4.4-pre1. for the 5 or so > minutes I've been using it so far, it seems okay (I'm able to log in this > time), and I'm running NetPIPE to check performance. > > Perfomance isn't great (the peak bandwidth is 65 Mbps or so), but this > could be partially due to my switch or the other machine I'm testing it > with. Okay, I've been running with 2.4.4-pre1 for awhile now, and although the driver does hang up on nfs traffic, it still has problems. After running for awhile, it seems to have dropouts of server hundred milliseconds where no packets go through. This is somewhat evident in interactive SSH sessions, and causes clients connecting to the squid proxy I am running on the machine to behave quite badly. (debian's 'apt' via the proxy is particulaly bad) -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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/
natsemi.c still broken...
On Wed, Apr 11, 2001 at 09:32:36PM -0500, Troy Benjegerdes wrote: On Wed, Mar 28, 2001 at 12:58:57PM -0500, Jeff Garzik wrote: There are some improvements in the latest 2.4 test patch, 2.4.3-pre8. I would be very interested in hearing feedback on that. I finally got two test cards, FA311 and FA312, so I can work on it a bit too. Okay, I finally got around to testing this on 2.4.4-pre1. for the 5 or so minutes I've been using it so far, it seems okay (I'm able to log in this time), and I'm running NetPIPE to check performance. Perfomance isn't great (the peak bandwidth is 65 Mbps or so), but this could be partially due to my switch or the other machine I'm testing it with. Okay, I've been running with 2.4.4-pre1 for awhile now, and although the driver does hang up on nfs traffic, it still has problems. After running for awhile, it seems to have dropouts of server hundred milliseconds where no packets go through. This is somewhat evident in interactive SSH sessions, and causes clients connecting to the squid proxy I am running on the machine to behave quite badly. (debian's 'apt' via the proxy is particulaly bad) -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: bug in natsemi driver 1.07 for linux 2.4.2
On Fri, Mar 30, 2001 at 07:04:29AM +0200, Sebastian Klemke wrote: Hi! The driver for the natsemi NIC does not properly filter out requested multicast groups when in multicast mode. Multicast groups I joined are simply dropped by the MAC address filter of the card, the kernel filters them correctly in allmulti or promiscuous mode. I've tested driver versions 1.05 which comes with linux 2.4.2, an older version that came with linux-2.4.0test12 and 1.07 which came with 2.4.2-ac20. I contacted Donald Becker and he told me to post it here. Have you tried Donald Becker's version of the driver under linux 2.2.x? The only natsemi driver I've ever had come close to working is in 2.4.4pre1, and even then it's got some problems that cause poor perfomance, nfs timeouts, and dropped connections with the squid http proxy. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: natsemi.c (Netgear FA311 card) probmlems??
On Wed, Mar 28, 2001 at 12:58:57PM -0500, Jeff Garzik wrote: > There are some improvements in the latest 2.4 test patch, 2.4.3-pre8. I > would be very interested in hearing feedback on that. I finally got two > test cards, FA311 and FA312, so I can work on it a bit too. Okay, I finally got around to testing this on 2.4.4-pre1. for the 5 or so minutes I've been using it so far, it seems okay (I'm able to log in this time), and I'm running NetPIPE to check performance. Perfomance isn't great (the peak bandwidth is 65 Mbps or so), but this could be partially due to my switch or the other machine I'm testing it with. > > The 2.4.3-pre8 patch, against kernel 2.4.2, is available from > ftp://ftp.us.kernel.org/pub/linux/kernel/testing/ > > This updated 2.4 natsemi.c merges the changes in Becker's latest, which > should fix eeprom/mac address reading as you mention, and it also > includes some power management fixes required on some boards. > Differences from 2.2 versions include locking updates and some other > small differences. Please test, if you have an opportunity. > > (note you'll have to fix a screwup of mine in drivers/net/Makefile -- > you need to add net_init.o to export-objs before you can build net > drivers as modules. Building them into the kernel works fine.) > > -- > Jeff Garzik | May you have warm words on a cold evening, > Building 1024 | a full moon on a dark night, > MandrakeSoft | and a smooth road all the way to your door. > -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: natsemi.c (Netgear FA311 card) probmlems??
On Wed, Mar 28, 2001 at 12:58:57PM -0500, Jeff Garzik wrote: There are some improvements in the latest 2.4 test patch, 2.4.3-pre8. I would be very interested in hearing feedback on that. I finally got two test cards, FA311 and FA312, so I can work on it a bit too. Okay, I finally got around to testing this on 2.4.4-pre1. for the 5 or so minutes I've been using it so far, it seems okay (I'm able to log in this time), and I'm running NetPIPE to check performance. Perfomance isn't great (the peak bandwidth is 65 Mbps or so), but this could be partially due to my switch or the other machine I'm testing it with. The 2.4.3-pre8 patch, against kernel 2.4.2, is available from ftp://ftp.us.kernel.org/pub/linux/kernel/testing/ This updated 2.4 natsemi.c merges the changes in Becker's latest, which should fix eeprom/mac address reading as you mention, and it also includes some power management fixes required on some boards. Differences from 2.2 versions include locking updates and some other small differences. Please test, if you have an opportunity. (note you'll have to fix a screwup of mine in drivers/net/Makefile -- you need to add net_init.o to export-objs before you can build net drivers as modules. Building them into the kernel works fine.) -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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/
natsemi.c (Netgear FA311 card) probmlems??
Is anyone succesfully using a FA311 card (or anthing with a NatSemi DP83815 chip?) The natsemi.c driver in 2.4.0 (and the one from Donald Becker's site for 2.2.x) Something seems to be handled incorrectly in the driver, because whenever I subject the card to moderate to heavy load (nfs does this most often), I get errors about 'eth0: something Wicked Happened 0700'. And usually after this happens a couple of times, the driver/card gets wedged and won't send/receive any more packets. The fa31lx70 driver from Netgear's web site at least doesn't get wedged, but has really poor perfomance under heavy load. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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/
natsemi.c (Netgear FA311 card) probmlems??
Is anyone succesfully using a FA311 card (or anthing with a NatSemi DP83815 chip?) The natsemi.c driver in 2.4.0 (and the one from Donald Becker's site for 2.2.x) Something seems to be handled incorrectly in the driver, because whenever I subject the card to moderate to heavy load (nfs does this most often), I get errors about 'eth0: something Wicked Happened 0700'. And usually after this happens a couple of times, the driver/card gets wedged and won't send/receive any more packets. The fa31lx70 driver from Netgear's web site at least doesn't get wedged, but has really poor perfomance under heavy load. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: regression tester
Cort Dougan wrote: >We have a start for PPC. It has the title "Regression Tester" but is >actually a "compiles and boots tester". The aim is a automated >regression test. >Take a look at http://altus.drgw.net/ I got a domain for this.. it works as 'hozed.org' and also the (sometimes appropriate) 'kernel.is.hozed.org' ;) >It pulls directly from our BitKeeper archive every time we push a change >and goes through the build targeted for a number of platforms. Right now, all the autobuilder part knows about is Bitkeeper, but it's designed so that one can easily add methods to pull from a CVS repository, or just plain old tarballs. >} - automated compilation of the kernel with random config >} options (done by Arjan v/d Ven?) >} - automated testing of certain kernel behaviour (didn't >} SGI have a project to look at this? could they use help?) >} - ... ? I need to write a design document for this thing so I don't have to explain it 300 times in emails.. The executive summary goes something like this: Goal: Distributed, scalable, cross-organization regression testing Problem: No one group has *all* the hardware linux runs on, so how can anyone know a particular patch doesn't break something? Solution: Automated tool builds kernels for multiple configurations (.config) files, and uploads kernels and build logs to a web server. (hozed.org, for my initial testing). Now, some joe random user with weird hardware can download the the kernel and a ramdisk containing a small, simple set of 'regression tests' that verify basic kernel functionality. This ramdisk then uploads the results to a web server, so that this requires no user interaction, other than downloading the kernel and ramdisk and booting them. Now, once the results are collected, kernel developers and look and see what changes to the kernel did to various machine types and stuff. One of my goals is to have a kernel 'tree' that one of the requirements for any patch to go in is that it passes the regression tests on a certain number and/or type of machines. In theory, if this works, anyone can download either the source or pre-built binaries, and have a really good idea that it *will* work. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: regression tester
Cort Dougan wrote: We have a start for PPC. It has the title "Regression Tester" but is actually a "compiles and boots tester". The aim is a automated regression test. Take a look at http://altus.drgw.net/ I got a domain for this.. it works as 'hozed.org' and also the (sometimes appropriate) 'kernel.is.hozed.org' ;) It pulls directly from our BitKeeper archive every time we push a change and goes through the build targeted for a number of platforms. Right now, all the autobuilder part knows about is Bitkeeper, but it's designed so that one can easily add methods to pull from a CVS repository, or just plain old tarballs. } - automated compilation of the kernel with random config } options (done by Arjan v/d Ven?) } - automated testing of certain kernel behaviour (didn't } SGI have a project to look at this? could they use help?) } - ... ? I need to write a design document for this thing so I don't have to explain it 300 times in emails.. The executive summary goes something like this: Goal: Distributed, scalable, cross-organization regression testing Problem: No one group has *all* the hardware linux runs on, so how can anyone know a particular patch doesn't break something? Solution: Automated tool builds kernels for multiple configurations (.config) files, and uploads kernels and build logs to a web server. (hozed.org, for my initial testing). Now, some joe random user with weird hardware can download the the kernel and a ramdisk containing a small, simple set of 'regression tests' that verify basic kernel functionality. This ramdisk then uploads the results to a web server, so that this requires no user interaction, other than downloading the kernel and ramdisk and booting them. Now, once the results are collected, kernel developers and look and see what changes to the kernel did to various machine types and stuff. One of my goals is to have a kernel 'tree' that one of the requirements for any patch to go in is that it passes the regression tests on a certain number and/or type of machines. In theory, if this works, anyone can download either the source or pre-built binaries, and have a really good idea that it *will* work. -- Troy Benjegerdes | master of mispeeling | 'da hozer' | [EMAIL PROTECTED] -"If this message isn't misspelled, I didn't write it" -- Me - "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shulz - 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: [ANNOUNCE] Darkstar Development Project
On Mon, 11 Sep 2000, Larry McVoy wrote: > > On Mon, Sep 11, 2000 at 01:13:56PM -0400, mberglund wrote: > > Name: > > Darkstar - an integrated operating system based on the Linux kernel > > and a stable set of tools. > [...] > > Development: > > In addition, by maintaining the system in CVS we can offer much > > faster and convenient source updates than are currently available > > from other Linux-based systems currently available. > > Err, "faster"? The following is the moral equiv of 4 kernel updates > which had nothing to do using BitKeeper instead of CVS. The local copy > was in San Francisco and the remote copy is Cort's machine in New Mexico > over a 384Kbits/sec link. All 4 updates in 5 seconds. Anyone have a > CVS tree they can try to get comparable numbers? > > At the risk of being slashdot-ed, you can browse these trees with BK's > replacement for CVSweb at http://www.bitkeeper.com/bkweb Cool... So can the latest version of the sources for BitKeeper be checked out too, or do we just have to write a script to extract it from the BkWeb changesets? :P - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
