Re: Panic - uma_zfree_arg - zone argument is NULL

[Gleb Smirnoff]

On Fri, Sep 26, 2014 at 08:30:06AM +0200, Hans Petter Selasky wrote:
H> On 09/26/14 08:06, Gleb Smirnoff wrote:
H> > On Fri, Sep 26, 2014 at 07:59:09AM +0200, Hans Petter Selasky wrote:
H> > H> On 09/26/14 07:51, Hans Petter Selasky wrote:
H> > H> > On 09/25/14 11:19, Gleb Smirnoff wrote:
H> > H> >> On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H> > H> >> H> #7  0x80b07863 in uma_zfree_arg (zone=0x0,
H> > H> >> item=0xf800114ee000,
H> > H> >> H>  udata=0x81484760)
H> > H> >>
H> > H> >> udata here is uma_slab_t. Can you look at it?
H> > H> >>
H> > H> >> btw, is that reproducible on stable/10 or head?
H> > H> >>
H> > H> >
H> > H> > Yes, it is reproducible. I have not tried stable/10 or head yet.
H> > H> >
H> > H> > (kgdb) print *(uma_slab_t)udata
H> > H> > $3 = {
H> > H> >us_keg = 0xf8085696d680,
H> >
H> > Can you print the us_keg, please?
H> 
H> (kgdb) print *(*(uma_slab_t)udata).us_keg
 

It is trash. This means that vtoslab() returned us bad pointer.

Either this mean the address passed to free() is invalid, and
belongs to a page not under UMA control, or someone else have
mangled the page belonging to UMA.

Can you please print *(struct vm_page *)0x81484760 ?

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic - uma_zfree_arg - zone argument is NULL

[Hans Petter Selasky]

On 09/26/14 08:06, Gleb Smirnoff wrote:

On Fri, Sep 26, 2014 at 07:59:09AM +0200, Hans Petter Selasky wrote:
H> On 09/26/14 07:51, Hans Petter Selasky wrote:
H> > On 09/25/14 11:19, Gleb Smirnoff wrote:
H> >> On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H> >> H> #7  0x80b07863 in uma_zfree_arg (zone=0x0,
H> >> item=0xf800114ee000,
H> >> H>  udata=0x81484760)
H> >>
H> >> udata here is uma_slab_t. Can you look at it?
H> >>
H> >> btw, is that reproducible on stable/10 or head?
H> >>
H> >
H> > Yes, it is reproducible. I have not tried stable/10 or head yet.
H> >
H> > (kgdb) print *(uma_slab_t)udata
H> > $3 = {
H> >us_keg = 0xf8085696d680,

Can you print the us_keg, please?



(kgdb) print *(*(uma_slab_t)udata).us_keg
$5 = {
  uk_lock = {
lock_object = {
  lo_name = 0xf8085696fd80 "\200\n\227V\b???\200?\226V\b???",
  lo_flags = 2168997728,
  lo_data = 4294967295,
  lo_witness = 0x0
},
mtx_lock = 0
  },
  uk_hash = {
uh_slab_hash = 0x0,
uh_hashsize = 0,
uh_hashmask = 0
  },
  uk_zones = {
lh_first = 0x0
  },
  uk_part_slab = {
lh_first = 0x224821000
  },
  uk_free_slab = {
lh_first = 0x0
  },
  uk_full_slab = {
lh_first = 0xf8085696d720
  },
  uk_align = 0,
  uk_pages = 6,
  uk_free = 0,
  uk_reserve = 1,
  uk_size = 131072,
  uk_rsize = 67044352,
  uk_maxpages = 269,
  uk_init = 0,
  uk_fini = 0x81484760 ,
  uk_allocf = 0xf8085696d7b8,
  uk_freef = 0xf80854307748,
  uk_offset = 18446744071584084984,
  uk_kva = 36435,
  uk_slabzone = 0x224822000,
  uk_slabsize = 0,
  uk_pgoff = 0,
  uk_ppera = 0,
  uk_ipers = 0,
  uk_flags = 1452726152,
  uk_name = 0x6 ,
  uk_link = {
le_next = 0x10001,
le_prev = 0x3ff0400
  }
}

--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic - uma_zfree_arg - zone argument is NULL

[Gleb Smirnoff]

On Fri, Sep 26, 2014 at 07:59:09AM +0200, Hans Petter Selasky wrote:
H> On 09/26/14 07:51, Hans Petter Selasky wrote:
H> > On 09/25/14 11:19, Gleb Smirnoff wrote:
H> >> On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H> >> H> #7  0x80b07863 in uma_zfree_arg (zone=0x0,
H> >> item=0xf800114ee000,
H> >> H>  udata=0x81484760)
H> >>
H> >> udata here is uma_slab_t. Can you look at it?
H> >>
H> >> btw, is that reproducible on stable/10 or head?
H> >>
H> >
H> > Yes, it is reproducible. I have not tried stable/10 or head yet.
H> >
H> > (kgdb) print *(uma_slab_t)udata
H> > $3 = {
H> >us_keg = 0xf8085696d680,

Can you print the us_keg, please?

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic - uma_zfree_arg - zone argument is NULL

[Hans Petter Selasky]

On 09/26/14 07:51, Hans Petter Selasky wrote:

On 09/25/14 11:19, Gleb Smirnoff wrote:

On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H> #7  0x80b07863 in uma_zfree_arg (zone=0x0,
item=0xf800114ee000,
H>  udata=0x81484760)

udata here is uma_slab_t. Can you look at it?

btw, is that reproducible on stable/10 or head?



Yes, it is reproducible. I have not tried stable/10 or head yet.

(kgdb) print *(uma_slab_t)udata
$3 = {
   us_keg = 0xf8085696d680,
   us_type = {
 _us_link = {
   le_next = 0xf80856970a80,
   le_prev = 0x3
 },
 _us_size = 18446735313429006976
   },
   us_hlink = {
 sle_next = 0x0
   },
   us_data = 0x81484778 "",
   us_free = {
 __bits = {0, 0, -2125969520, 0}
   },
   us_freecount = 0,
   us_flags = 0 '\0',
   us_pad = 0 '\0'
}



BTW: I don't rule out that this might be an indirect error of some other 
kernel modules which I am experimenting with currently. But if you see 
something which is obvious then please let me know.


--HPS

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic - uma_zfree_arg - zone argument is NULL

[Hans Petter Selasky]

On 09/25/14 11:19, Gleb Smirnoff wrote:

On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H> #7  0x80b07863 in uma_zfree_arg (zone=0x0, item=0xf800114ee000,
H>  udata=0x81484760)

udata here is uma_slab_t. Can you look at it?

btw, is that reproducible on stable/10 or head?



Yes, it is reproducible. I have not tried stable/10 or head yet.

(kgdb) print *(uma_slab_t)udata
$3 = {
  us_keg = 0xf8085696d680,
  us_type = {
_us_link = {
  le_next = 0xf80856970a80,
  le_prev = 0x3
},
_us_size = 18446735313429006976
  },
  us_hlink = {
sle_next = 0x0
  },
  us_data = 0x81484778 "",
  us_free = {
__bits = {0, 0, -2125969520, 0}
  },
  us_freecount = 0,
  us_flags = 0 '\0',
  us_pad = 0 '\0'
}

--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Boot failure with r272146

[Justin Hibbits]

With r272146 my SATA controller fails to attach, preventing the kernel
from mounting root.  I've attached a log of as much as dconschat would
allow.  The relevant portion is pcib10:

atapci0:  mem 0xfa402000-0xfa403fff
at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10
pcib10: failed to allocate initial I/O port window (0-0x,0x10)
atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x).
atapci0: unable to map interrupt
device_attach: atapci0 attach returned 6

pcib10: allocated memory range (0xfa40-0xfa400fff) for rid 10 of
pci1:3:14:0 atapci0:  mem
0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve
resource for pcib10 pcib10: failed to allocate initial I/O port window
(0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0,
0x). atapci0: unable to map interrupt
device_attach: atapci0 attach returned 6
ata0:  mem 0xfa404000-0xfa407fff at device
13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384
ata0: unable to allocate interrupt
device_attach: ata0 attach returned 6


It works fine with r271697 kernel (latest I have booting).  I haven't
yet tried bisecting.

Hardware is a PowerMac G5 (last generation).

- Justin

kernel_boot.fail
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AHCI after 271145 does not work for me

[Warner Losh]

On Sep 25, 2014, at 1:59 PM, José Pérez Arauzo  wrote:

> On Thu, 25 Sep 2014 09:26:56 -0700, David Wolfskill wrote
>> On Thu, Sep 25, 2014 at 05:48:13PM +0200, José Pérez Arauzo wrote:
>>> Hi,
>>> on my Acer Aspire V5, AHCI does not complete device_attach after 271145.
>>> 
>>> Am I the only one experiencing this? Can I help fixing it? Thank you.
> [...]
>> As for debugging, a start will be to collect the AHCI controller
>> information for "pciconf -lv", as well as dmesg information -- e.g.:
> 
> Thank you David, here are pciconf and dmesg:
> 
> ahci0@pci0:0:17:0:  class=0x01018f card=0x080d1025 chip=0x78001022
> rev=0x40 hdr=0x00
>vendor = 'Advanced Micro Devices [AMD]'
>device = 'Hudson SATA Controller [IDE mode]'
>class  = mass storage
>subclass   = ATA
> 
>> dmesg | fgrep -i ahci
> ahci0:  port
> 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem
> 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0
> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS
> ahcich0:  at channel 0 on ahci0
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> ahci0:  port
> 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem
> 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0
> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS
> ahcich0:  at channel 0 on ahci0
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> ahci0:  port
> 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem
> 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0
> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS
> ahcich0:  at channel 0 on ahci0
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> 
> 
> For the sake of completeness: there's a BIOS option to either set the hw to
> present itself as legacy ISA or AHCI, but the kernel hangs in any case.

Do you have before messages too?

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: AHCI after 271145 does not work for me

[Warner Losh]

Also r271201 fixes an issue with interrupts. Have you tried anything newer?

Warner


On Sep 25, 2014, at 9:12 AM, Adrian Chadd  wrote:

> Hi!
> 
> 271146 was Warner's AHCI probe/attach changes. Maybe he'll have some ideas. :)
> 
> Warner?
> 
> 
> -a
> 
> 
> On 25 September 2014 08:48, José Pérez Arauzo  wrote:
>> Hi,
>> on my Acer Aspire V5, AHCI does not complete device_attach after 271145.
>> 
>> Am I the only one experiencing this? Can I help fixing it? Thank you.
>> 
>> BR,
>> 
>> --
>> José Pérez Arauzo
>> 
>> ___
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: AHCI after 271145 does not work for me

[Warner Losh]

I’m afraid I have no clue. I’ll need hardware to debug this, since I don’t have 
any, or someone that can provide some feedback or even probe messages with it 
going off the rails (before/after).

Warner

On Sep 25, 2014, at 9:12 AM, Adrian Chadd  wrote:

> Hi!
> 
> 271146 was Warner's AHCI probe/attach changes. Maybe he'll have some ideas. :)
> 
> Warner?
> 
> 
> -a
> 
> 
> On 25 September 2014 08:48, José Pérez Arauzo  wrote:
>> Hi,
>> on my Acer Aspire V5, AHCI does not complete device_attach after 271145.
>> 
>> Am I the only one experiencing this? Can I help fixing it? Thank you.
>> 
>> BR,
>> 
>> --
>> José Pérez Arauzo
>> 
>> ___
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Cam panic on r271170

[Bryan Drewery]

On 9/17/2014 10:39 AM, Bryan Drewery wrote:
> On 9/16/2014 9:28 PM, Bryan Drewery wrote:
>> I've been getting this quite frequently on head recently. I have dumps
>> if anyone is interested in more information.
>>
>>> Fatal trap 9: general protection fault while in kernel mode
>>> cpuid = 10; Memory modified after free 0xf8003e0b0800(2040)
>>> val= @ 0xf8003e0b0808
>>> apanic: Most recently used by CAM CCB
>>>
>>> cpuid = 6
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>> 0xfe124735b4c0
>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124735b570
>>> vpanic() at vpanic+0x189/frame 0xfe124735b5f0
>>> panic() at panic+0x43/frame 0xfe124735b650
>>> mtrash_ctor() at mtrash_ctor+0x8a/frame 0xfe124735b680
>>> uma_zalloc_arg() at uma_zalloc_arg+0x4f1/frame 0xfe124735b6f0
>>> malloc() at malloc+0x192/frame 0xfe124735b740
>>> xpt_run_allocq() at xpt_run_allocq+0xb5/frame 0xfe124735b780
>>> adastrategy() at adastrategy+0x117/frame 0xfe124735b7b0
>>> g_io_request() at g_io_request+0x3b7/frame 0xfe124735b810
>>> g_part_start() at g_part_start+0x2b7/frame 0xfe124735b890
>>> g_io_request() at g_io_request+0x3b7/frame 0xfe124735b8f0
>>> g_io_request() at g_io_request+0x3b7/frame 0xfe124735b950
>>> vdev_geom_io_start() at vdev_geom_io_start+0x137/frame 0xfe124735b970
>>> zio_vdev_io_start() at zio_vdev_io_start+0x49f/frame 0xfe124735b9d0
>>> zio_execute() at zio_execute+0x204/frame 0xfe124735ba30
>>> vdev_queue_io_done() at vdev_queue_io_done+0x180/frame 0xfe124735ba80
>>> zio_vdev_io_done() at zio_vdev_io_done+0x11d/frame 0xfe124735bac0
>>> zio_execute() at zio_execute+0x204/frame 0xfe124735bb20
>>> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame
>>> 0xfe124735bb80
>>> taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame
>>> 0xfe124735bbb0
>>> fork_exit() at fork_exit+0x84/frame 0xfe124735bbf0
>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe124735bbf0
>>> --- trap 0, rip = 0, rsp = 0xfe124735bcb0, rbp = 0 ---
>>> KDB: enter: panic
>>> [ thread pid 0 tid 100571 ]
>>> Stopped at  kdb_enter+0x3e: movq$0,kdb_why
>>
>>

Not sure about this one. We've been getting it at work as well based on
a stable/10ish tree.

> 
> I also had this one recently:
> 
>> #8  0x80d1a162 in calltrap () at 
>> /usr/src/sys/amd64/amd64/exception.S:231
>> #9  0x802e52c4 in xpt_path_periph (path=0xdeadc0dedeadc0de) at 
>> /usr/src/sys/cam/cam_xpt.c:3738
>> #10 0x802dfe62 in cam_periph_error (ccb=0xf8003e0b6000, 
>> camflags=CAM_FLAG_NONE, sense_flags=0, save_ccb=0x0) at 
>> /usr/src/sys/cam/cam_periph.c:1602
>> #11 0x803057e4 in adadone (periph=0xf8003e09b700, 
>> done_ccb=0xf8003e0b6000) at /usr/src/sys/cam/ata/ata_da.c:1877
>> #12 0x802e6e44 in xpt_done_process (ccb_h=0xf8003e0b6000) at 
>> /usr/src/sys/cam/cam_xpt.c:5245
>> #13 0x80394d59 in ahci_ch_intr_direct (arg=) at 
>> /usr/src/sys/dev/ahci/ahci.c:1132
>> #14 0x80390ff1 in ahci_intr (data=) at 
>> /usr/src/sys/dev/ahci/ahci.c:417
>> #15 0x808ea5d3 in intr_event_execute_handlers (p=> out>, ie=0xf8000f725d00) at /usr/src/sys/kern/kern_intr.c:1252
>> #16 0x808eafb6 in ithread_loop (arg=0xf8000f6dea60) at 
>> /usr/src/sys/kern/kern_intr.c:1265
>> #17 0x808e7fc4 in fork_exit (callout=0x808eaf10 
>> , arg=0xf8000f6dea60, frame=0xfe1245083c00) at 
>> /usr/src/sys/kern/kern_fork.c:977
>> #18 0x80d1a69e in fork_trampoline () at 
>> /usr/src/sys/amd64/amd64/exception.S:605
> 

This one however (and all subsequent traces I posted) was resolved by
r271201.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: IXP700 AHCI fails to initialize

[Yuriy Taraday]

On Mon, Mar 3, 2014 at 2:22 PM, Roger Pau Monné 
wrote:

> On 01/03/14 19:00, Yuriy Taraday wrote:
> > Hello.
> >
> > I currently have FreeBSD 8.3 on my home server and it works fine but it's
> > time to upgrade at last (new ath and new ipfw especially allure me). I've
> > decided to go straight to 10.0 and reinstall system from scratch to purge
> > all legacy unrelated configs and other stuff.
> >
> > The problem I faced is as follows. I have a (rather old) motherboard with
> > integrated SATA controller that presents in the OS as IXP700. In 8.3 it
> > works fine. I have 2 disks attached to it: one with all my data and
> another
> > one destined to be new system disk. I also have one IDE disk installed
> that
> > is currently used as system disk.
> >
> > When I booted from USB stick with 10.0, I couldn't see any SATA disks in
> > the system. I dug into dmesg and found this:
> http://pastebin.com/wv2A0MUE
> > As it seems AHCI controller or disks are not responding to commands and
> > timeouts eventually.
> >
> > A friend suggested to try CURRENT image. I went
> > with FreeBSD-11.0-CURRENT-amd64-VT-20140222-r262336-mini-memstick.img and
> > got almost the same error: http://pastebin.com/0iGaSWUD
> > The error repeats and never stops (looks like CURRENT images have
> different
> > config) but it is essentially the same.
> >
> > I've googled the problem but found only notes about how IXP700 is really
> > bad and pointers that cabling might be the problem. But I have absolutely
> > no problems with 8.3, so it looks like some regression during further
> > development (shift to CAM, maybe?).
> >
> > Please help me to identify and fix the problem.
>
> This is just a shot in the dark, I'm not familiar with the AHCI driver,
> but since you seem to be loosing interrupts (or I would say so based on
> the timeout messages), you could try to disable MSI/MSI-X and fallback
> to PCI intline IRQs. Could you try to boot with
> hw.pci.enable_msix=0,hw.pci.enable_msi=0?
>

A flood of RC news in my feed forced me to get back to upgrading my
homeserver.
I've tried out 10.1-BETA2 image and got the same results.
Then I've tried to provide these options you suggested, and although there
were some hickup (HDDs didn't respond well at first, I guess), I got to
bsdinstall prompt. Thank you very much for suggestion!

Now I wonder what would be the impact of having these options disabled
permanently. Will there be a huge slowdown of all PCI cards? Or
should it be negligible?

-- 

Kind regards, Yuriy.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AHCI after 271145 does not work for me

[José Pérez Arauzo]

On Thu, 25 Sep 2014 09:26:56 -0700, David Wolfskill wrote
> On Thu, Sep 25, 2014 at 05:48:13PM +0200, José Pérez Arauzo wrote:
> > Hi,
> > on my Acer Aspire V5, AHCI does not complete device_attach after 271145.
> > 
> > Am I the only one experiencing this? Can I help fixing it? Thank you.
[...]
> As for debugging, a start will be to collect the AHCI controller
> information for "pciconf -lv", as well as dmesg information -- e.g.:

Thank you David, here are pciconf and dmesg:

ahci0@pci0:0:17:0:  class=0x01018f card=0x080d1025 chip=0x78001022
rev=0x40 hdr=0x00
vendor = 'Advanced Micro Devices [AMD]'
device = 'Hudson SATA Controller [IDE mode]'
class  = mass storage
subclass   = ATA

> dmesg | fgrep -i ahci
ahci0:  port
0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem
0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0
ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS
ahcich0:  at channel 0 on ahci0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ahci0:  port
0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem
0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0
ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS
ahcich0:  at channel 0 on ahci0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ahci0:  port
0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem
0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0
ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS
ahcich0:  at channel 0 on ahci0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0


For the sake of completeness: there's a BIOS option to either set the hw to
present itself as legacy ISA or AHCI, but the kernel hangs in any case.


BR,


--
José Pérez Arauzo

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Poor state of the build infrastructure.

[Ian Lepore]

On Thu, 2014-09-25 at 14:50 -0400, John Baldwin wrote:
> On Wednesday, September 24, 2014 7:33:46 pm Marcel Moolenaar wrote:
> > 
> > On Sep 24, 2014, at 12:54 PM, John Baldwin  wrote:
> > 
> > > On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote:
> > >> What is going on here?
> > >> Are we still in some kind of flux and people aren't done yet or is
> > >> this the intended state by virtue of noone having anything left on
> > >> there TODO list?
> > > 
> > > Sorry to ask a dumb question, but are you sure you did the make 
> > > buildworld 
> > > first?  Shouldn't that have errored if it couldn't build crt1?
> > 
> > The root cause problem was that MAKEOBJDIRPREFIX was not set
> > to whatever it was set to during buildworld. That was easy
> > enough to figure out when a bunch of things don't add up.
> 
> Ok.
> 
> > But neither problem mentioned in the email had anything to
> > do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE
> > as part of an install is a bug. Entering a powerpc buildenv
> > and having a compiler that builds for the host (or maybe
> > just some default) is a regression.
> 
> Agreed on COMPILER_TYPE, but I think the path thing has always been true in 
> make buildenv because we don't build cross-tools for things like 'cp'.
> 

Just to be clear, all the problems in the original mail, including
failure to detect COMPILER_TYPE automatically and building the wrong
type of binaries, were fallout from the original problem of not setting
MAKEOBJDIRPREFIX correctly.  It turns out if you use the build system
correctly, it works!  (Unfortunately, using it correctly requires
knowing about a whole lotta knobs to be set these days if your needs are
not vanilla.)

-- Ian


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Poor state of the build infrastructure.

[John Baldwin]

On Wednesday, September 24, 2014 7:33:46 pm Marcel Moolenaar wrote:
> 
> On Sep 24, 2014, at 12:54 PM, John Baldwin  wrote:
> 
> > On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote:
> >> What is going on here?
> >> Are we still in some kind of flux and people aren't done yet or is
> >> this the intended state by virtue of noone having anything left on
> >> there TODO list?
> > 
> > Sorry to ask a dumb question, but are you sure you did the make buildworld 
> > first?  Shouldn't that have errored if it couldn't build crt1?
> 
> The root cause problem was that MAKEOBJDIRPREFIX was not set
> to whatever it was set to during buildworld. That was easy
> enough to figure out when a bunch of things don't add up.

Ok.

> But neither problem mentioned in the email had anything to
> do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE
> as part of an install is a bug. Entering a powerpc buildenv
> and having a compiler that builds for the host (or maybe
> just some default) is a regression.

Agreed on COMPILER_TYPE, but I think the path thing has always been true in 
make buildenv because we don't build cross-tools for things like 'cp'.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCHES] Convert various pc98 drivers from timeout() to callout()

[John Baldwin]

On Thursday, September 25, 2014 11:15:51 am TAKAHASHI Yoshihiro wrote:
> In article <2960329.sjarrui...@ralph.baldwin.cx>
> John Baldwin  writes:
> 
> > I have three patches to convert various pc98 drivers from timeout() to 
> > callout().  For the fdc driver I took a more drastic approach and have 
> > attempted to port the PC98 support into the main fdc driver:
> 
> Great!
> 
> Unfortunately, I don't have enough time to review and test your
> patches so please feel free to commit them.  When I have time, I'll
> check.
> 
> Thanks for your work.

Ok.  I'm mostly nervous about the fdc(4) patch, but I will move forward.  
Thanks!

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: installworld broken - osreldate.h: permission denied

[Harald Schmalzbauer]

 Bezüglich Ian Lepore's Nachricht vom 28.09.2013 19:19 (localtime):
> On Sat, 2013-09-28 at 15:09 +0200, Joel Dahl wrote:
>> Hi,
>>
>> Fresh HEAD. installworld from read-only /usr/obj and /usr/src:
>>
>> /usr/src/include/iconv.h osreldate.h /usr/include
>> install: osreldate.h: Permission denied
>> *** Error code 71
>>
>> Stop.
>> make[4]: stopped in /usr/src/include
>> *** Error code 1
>>
>> Everything was working fine 2 weeks ago, so it's a recent breakage.
>>
> Okay, I just accidentally created conditions for this error on my
> system...  I checked in a change to newvers.sh while a buildworld was
> running, which led to a situation where newvers.sh was newer than
> osreldate.h at the end of the buildworld.  Then an installworld tried to
> regenerate osreldate.h due to its dependency on newvers.sh, which would
> fail if the obj was readonly at that point.
>
> I think we could see if something similar applies for you if you use
> this command:
>
>   make -dm installworld SUBDIR_OVERRIDE=include
>
> And we'd be looking for the end of the output to be something like:
>
> Examining _libiconv_compat.h...
> modified 10:51:18 Sep 28, 2013...up-to-date
> Make_Update: _libiconv_compat.h
> inspect parent buildincludes: flags 0, type 18001, made 0, unmade 95 - not 
> needed
> inspect parent _INCSINS: flags 9, type b01, made 1, unmade 1 - unmade 
> children
> Examining osreldate.h...
> modified 10:39:21 Sep 28, 2013...modified before source 
> /local/build/staging/freebsd/head/src/include/../sys/conf/newvers.sh...out-of-date
> env ECHO="echo"  
> MAKE="/local/build/staging/freebsd/head/obj/local/build/staging/freebsd/head/src/make.i386/bmake"
>   
> NEWVERS_SH=/local/build/staging/freebsd/head/src/include/../sys/conf/newvers.sh
>   PARAM_H=/local/build/staging/freebsd/head/src/include/../sys/sys/param.h  
> SYSDIR=/local/build/staging/freebsd/head/src/include/../sys  sh 
> /local/build/staging/freebsd/head/src/include/mk-osreldate.sh
> env: not found
> *** [osreldate.h] Error code 127
>
> The "env: not found" is what I got instead of a permission denied, and
> probably has something to do with me cross-building amd64 10.0 from an
> i386 8.x machine.  I think that's where you'd see the permission error.
>
> If the same sort of thing is happening for you, then all that's left is
> to figure out why osreldate.h is out of date at install time, and how to
> handle things if that's the case.

Thanks for your suggestion how to best find out what's going on.
I have the same problem you observed (env: not found), not the
permission problem the thread opener had.

For any reason, not relevant at this point, my
${src}/sys/conf/newvers.sh is newer than 'include/osreldate.h' under
$OBJDIRPREFIX/i386.i386/….

Now in 'include/Makefile', "sh ${MK_OSRELDATE_SH}" should be called by
'env' in target 'osreldate.h vers.c:'.
Problem is, that PATH has sevaral bin-sbin directories under
"$OBJDIRPREFIX/…/tmp/" _and_ "$INSTALLTMP", and none of them provides 'env'.
The latter is filled with target 'distributeworld installworld:' in
Makefile.inc1, with $ITOOLS.

The following additional tools are missing in ITOOLS
to make recreating osreldate.h work at installworld stage:
env, hostname, mktemp and touch

So a patch to work arround that issue looks like this:
--- src/Makefile.inc1.orig 2014-09-25 17:36:16.0 +0200
+++ src/Makefile.inc1 2014-09-25 17:47:14.0 +0200
@@ -697,9 +697,9 @@
.endif

ITOOLS= [ awk cap_mkdb cat chflags chmod chown \
- date echo egrep find grep id install ${_install-info} \
- ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ date echo egrep env find grep hostname id install ${_install-info} \
+ ln lockf make mkdir mktemp mtree ${_nmtree_itools} mv pwd_mkdb \
+ rm sed sh sysctl test touch true uname wc ${_zoneinfo}

#
# distributeworld

I have no idea if there's a better way, but if these tools are not to be
added, the check for outdated osreldate.h should be disabled because
recreation at install stage is not possible without. At least this is
true for compiling 9.3-i386 on 10-stable-amd64.

-Harry



signature.asc
Description: OpenPGP digital signature

Re: AHCI after 271145 does not work for me

[David Wolfskill]

On Thu, Sep 25, 2014 at 05:48:13PM +0200, José Pérez Arauzo wrote:
> Hi,
> on my Acer Aspire V5, AHCI does not complete device_attach after 271145.
> 
> Am I the only one experiencing this? Can I help fixing it? Thank you.
> ...

Well, I am not experiencing such a problem on my Dell M4400; you can see
nearly a year's worth of (mostly daily) "uname -vp" entries for head at
.

Today's "uname -a" is:

FreeBSD g1-235.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1378  
r272099M/272101:1100036: Thu Sep 25 06:30:23 PDT 2014 
r...@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386


As for 271145, I bracketed that one in early September:

FreeBSD 11.0-CURRENT #1360  r271089M/271091:1100030: Thu Sep  4 06:31:23 PDT 
2014 r...@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386

FreeBSD 11.0-CURRENT #1361  r271156M/271156:1100030: Fri Sep  5 07:47:32 PDT 
2014 root@localhost:/common/S4/obj/usr/src/sys/CANARY  i386

(Second one was recorded while I was on the train during my commute
to work.)


As for debugging, a start will be to collect the AHCI controller
information for "pciconf -lv", as well as dmesg information -- e.g.:

ahci0@pci0:0:31:2:  class=0x010601 card=0x02501028 chip=0x29298086
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'ICH9M/M-E SATA AHCI Controller'
class  = mass storage
subclass   = SATA

ahci0:  port
0x6e70-0x6e77,0x6e78-0x6e7b,0x6e80-0x6e87,0x6e88-0x6e8b,0x6ea0-0x6ebf
mem 0xfed1c800-0xfed1cfff irq 19 at device 31.2 on pci0
ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported
ahcich0:  at channel 0 on ahci0
ahcich1:  at channel 1 on ahci0
ahcich4:  at channel 4 on ahci0
ahcich5:  at channel 5 on ahci0
ahciem0:  on ahci0

But you'll undoubtedly get better information from folks who are
more familiar with the hardware and the code than I am.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil cowards with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpQSeywjo1Zd.pgp
Description: PGP signature

Re: AHCI after 271145 does not work for me

[Adrian Chadd]

Hi!

271146 was Warner's AHCI probe/attach changes. Maybe he'll have some ideas. :)

Warner?


-a


On 25 September 2014 08:48, José Pérez Arauzo  wrote:
> Hi,
> on my Acer Aspire V5, AHCI does not complete device_attach after 271145.
>
> Am I the only one experiencing this? Can I help fixing it? Thank you.
>
> BR,
>
> --
> José Pérez Arauzo
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

AHCI after 271145 does not work for me

[José Pérez Arauzo]

Hi,
on my Acer Aspire V5, AHCI does not complete device_attach after 271145.

Am I the only one experiencing this? Can I help fixing it? Thank you.

BR,

--
José Pérez Arauzo

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCHES] Convert various pc98 drivers from timeout() to callout()

[TAKAHASHI Yoshihiro]

In article <2960329.sjarrui...@ralph.baldwin.cx>
John Baldwin  writes:

> I have three patches to convert various pc98 drivers from timeout() to 
> callout().  For the fdc driver I took a more drastic approach and have 
> attempted to port the PC98 support into the main fdc driver:

Great!

Unfortunately, I don't have enough time to review and test your
patches so please feel free to commit them.  When I have time, I'll
check.

Thanks for your work.

---
TAKAHASHI Yoshihiro 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic - uma_zfree_arg - zone argument is NULL

[Gleb Smirnoff]

On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H> #7  0x80b07863 in uma_zfree_arg (zone=0x0, item=0xf800114ee000,
H>  udata=0x81484760)

udata here is uma_slab_t. Can you look at it?

btw, is that reproducible on stable/10 or head?

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"