headers
YAMAMOTO Takashi | 1 Jan 2008 22:57
Picon

Re: per-cpu TSS

> i want to get rid of ltr from cpu_switchto.

the following is a result of "fmt.sh <tprof.out|head -30".
tprof.out here was taken while running mysql sysbench.
"cpu_switchto+0x4f" is the next address of the ltr instruction.

YAMAMOTO Takashi

13259   c039b98a        x86_pause+0x2
7652    c039b571        bus_space_read_4+0x11
2735    c010ce12        mutex_enter+0x12
2308    c02dd845        _kernel_lock+0xc5
2182    c010cfcd        __cpu_simple_lock_try+0xd
1824    c010cef5        mutex_spin_enter+0x35
1536    c039b988        x86_pause
1525    c01005c4        sse2_zero_page+0x14
1515    c0100c4c        spllower+0x2c
1384    c01005c0        sse2_zero_page+0x10
1379    c0100490        Xsyscall
1285    c039ef5f        invlpg+0x7
1234    c010cf9d        __cpu_simple_lock+0xd
737     c01003cf        cpu_switchto+0x4f
732     c0100fb9        Xintr_lapic_tlb_mcast+0x49
710     c02dd84e        _kernel_lock+0xce
641     bb86b9a7        start
634     bb9002a7        start
609     c01006fc        copyout+0x3c
609     c010ce5f        rw_enter+0x1f
577     c02abc50        nonresident_rotate+0x10
576     c0100523        syscall1+0x91
(Continue reading)

Permalink | Reply | 2 comments |
headers
Perry E. Metzger | 2 Jan 2008 01:22
Gravatar

Re: per-cpu TSS


yamt <at> mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>> i want to get rid of ltr from cpu_switchto.
>
> the following is a result of "fmt.sh <tprof.out|head -30".
> tprof.out here was taken while running mysql sysbench.
> "cpu_switchto+0x4f" is the next address of the ltr instruction.

How does one interpret the output of tprof/fmt.sh?

Perry

> 13259   c039b98a        x86_pause+0x2
> 7652    c039b571        bus_space_read_4+0x11
> 2735    c010ce12        mutex_enter+0x12
> 2308    c02dd845        _kernel_lock+0xc5
> 2182    c010cfcd        __cpu_simple_lock_try+0xd
> 1824    c010cef5        mutex_spin_enter+0x35
> 1536    c039b988        x86_pause
> 1525    c01005c4        sse2_zero_page+0x14
> 1515    c0100c4c        spllower+0x2c
> 1384    c01005c0        sse2_zero_page+0x10
> 1379    c0100490        Xsyscall
> 1285    c039ef5f        invlpg+0x7
> 1234    c010cf9d        __cpu_simple_lock+0xd
> 737     c01003cf        cpu_switchto+0x4f
> 732     c0100fb9        Xintr_lapic_tlb_mcast+0x49
> 710     c02dd84e        _kernel_lock+0xce
> 641     bb86b9a7        start
> 634     bb9002a7        start
(Continue reading)

Permalink | Reply | 1 comment |
headers
YAMAMOTO Takashi | 2 Jan 2008 02:20
Picon

Re: per-cpu TSS

> How does one interpret the output of tprof/fmt.sh?

see README.

YAMAMOTO Takashi
Permalink | Reply | 0 comments |
headers
Stephen Borrill | 4 Jan 2008 17:01
Picon
Favicon

Using bootxx_fat16

I've tried to get bootxx_fat16 + boot working.

I took a pen drive, formatted it under Windows to ensure it had a clean 
FAT (not FAT32) filesystem, then copied /boot and a kernel to the 
filesystem.

laptop# mount_msdos /dev/sd0e /mnt
laptop# ls /mnt
BOOT	NETBSD

I set the first partition as active. bootxx_fat16 is doing its magic 
loading /boot. However, once in the boot loader, I can't find a working 
path to the kernel. I've tried:

hd0a:netbsd
hd0a:NETBSD
hd0e:netbsd
hd0e:NETBSD

I've also tried copying the kernel on with the -s and -l options to 
mount_msdos (not at the same time!).

What am I missing?

--

-- 
Stephen
Permalink | Reply | 3 comments |
headers
Alan Barrett | 4 Jan 2008 17:34
Gravatar

Re: Using bootxx_fat16

On Fri, 04 Jan 2008, Stephen Borrill wrote:
> I took a pen drive, formatted it under Windows to ensure it had a clean FAT 
> (not FAT32) filesystem, then copied /boot and a kernel to the filesystem.
> [...]
> I set the first partition as active. bootxx_fat16 is doing its magic 
> loading /boot. However, once in the boot loader, I can't find a working 
> path to the kernel.

I had a similar problem, which went away when I added a disklabel
(in the space between the MBR and the start of the FAT partition).

--apb (Alan Barrett)
Permalink | Reply | 2 comments |
headers
Stephen Borrill | 4 Jan 2008 17:44
Picon
Favicon

Re: Using bootxx_fat16

On Fri, 4 Jan 2008, Alan Barrett wrote:
> On Fri, 04 Jan 2008, Stephen Borrill wrote:
>> I took a pen drive, formatted it under Windows to ensure it had a clean FAT
>> (not FAT32) filesystem, then copied /boot and a kernel to the filesystem.
>> [...]
>> I set the first partition as active. bootxx_fat16 is doing its magic
>> loading /boot. However, once in the boot loader, I can't find a working
>> path to the kernel.
>
> I had a similar problem, which went away when I added a disklabel
> (in the space between the MBR and the start of the FAT partition).

disklabel -I -e sd0 to save a hard copy of the fabricated disklabel worked 
fine. Thanks Alan!

This isn't alluded to anywhere in the documentation though. I'm not 
convinced it should be necessary either...

--

-- 
Stephen
Permalink | Reply | 0 comments |
headers
David Laight | 4 Jan 2008 20:56
Picon

Re: Using bootxx_fat16

On Fri, Jan 04, 2008 at 06:34:55PM +0200, Alan Barrett wrote:
> On Fri, 04 Jan 2008, Stephen Borrill wrote:
> > I took a pen drive, formatted it under Windows to ensure it had a clean FAT 
> > (not FAT32) filesystem, then copied /boot and a kernel to the filesystem.
> > [...]
> > I set the first partition as active. bootxx_fat16 is doing its magic 
> > loading /boot. However, once in the boot loader, I can't find a working 
> > path to the kernel.
> 
> I had a similar problem, which went away when I added a disklabel
> (in the space between the MBR and the start of the FAT partition).

/boot should contain code to 'fake up' a valid disklabel from the
mbr information.  See read_label() in stand/lib/biosdisk.c

hmmm.... looks like I have some local changes in that file :-)

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 5 Jan 2008 13:55

Re: [ANNOUNCEMENT] The pkgsrc-2007Q4 Branch

On Sat, Jan 05, 2008 at 08:03:12AM +0000, Alistair Crooks wrote:
> 
> The pkgsrc-2007Q4 Branch
> ========================
> 
> The pkgsrc developers are very proud to announce the new pkgsrc-2007Q4
> branch, which has support for more packages than previous branches. 
> [...]

As I did for the previous branches, I'll provide binary packages for
NetBSD/2.1, 3.1 and 4.0 i386 and amd64; and NetBSD/3.1 and 4.0 for sparc.
I'll do regular builds of the branch to keep the binaries up to date.

Expect binaries to show up in a few days for i386, 10 to 15 days for amd64
and 3 to 4 weeks for sparc.

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--
Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 5 Jan 2008 16:50
Picon

Re: CVS commit: src/regress/sys/arch/i386

[ cc: port-i386 ]

> On Fri, Jan 04, 2008 at 07:27:05PM +0100, Matthias Drochner wrote:
> 
> > 
> > yamt <at> NetBSD.org said:
> > > Log Message: test i386_get_ioperm/i386_set_ioperm. 
> > 
> > This reminds me of something: Because this syscall is
> > practically useless and the bitmap just uses up pcb bits
> > and kernel stack, I had once reduced it to a COMPAT
> > option, setting iopl if any access is allowed by the
> > bitmap, somewhere in a local tree, before the i386/amd64
> > unification.
> > This would make that the (faked) bitmap returned by
> > get_ioperm() would not necessarily be identical to the one
> > sent by set_ioperm(). I didn't find any userland program
> > using the ioperm calls, let alone reading back the bitmasks.
> > So how about getting the bitmask removed?
> 
> I think we should get rid of it the bitmap and adjust the iopl. I can't
> think of any good reason to provide the interface. It did have users the
> last time I looked, try Google codesearch.
> 
> Andrew

i have no problem with the removal of the bitmap.

YAMAMOTO Takashi
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthias Drochner | 6 Jan 2008 16:35
Picon
Picon
Favicon

Re: CVS commit: src/regress/sys/arch/i386


yamt <at> mwd.biglobe.ne.jp said:
> i have no problem with the removal of the bitmap. 

OK, so I'll try to find these patches...

best regards
Matthias

-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich

Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
Permalink | Reply | 0 comments |

Gmane